Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.nomos.energy/llms.txt

Use this file to discover all available pages before exploring further.

​
Get customer-consented access via OAuth 2.0

Standard authorization-code flow with PKCE. Your app (a HEMS, an EV charger, a home-automation hub) redirects the customer to /oauth/authorize with your client_id and pre-registered redirect_uri. After they approve on a Nomos-hosted consent page, your backend exchanges the resulting code at /oauth/token for a short-lived access token plus a rotating refresh token.
Hosted sign-in page asking the customer for the email address tied to their Nomos contract
Hosted verification page with six input boxes for the one-time code
Hosted consent screen listing the data scopes the application is requesting, with allow and deny buttons
This is the right flow if you act on behalf of a customer. If you’re an organization on Nomos and just need server-to-server access to your own data, use the Client Credentials grant instead.

​
What you can do with the access token

Tokens minted through this flow are scoped to a single customer. They authorize the same read endpoints the customer sees in their portal: subscriptions, prices, consumption, invoices. They don’t authorize writes. Access tokens last 60 minutes. Refresh tokens rotate on every use, so always persist the new one and call /oauth/token again before the access token expires. For full request and response shapes, including PKCE details, see Authentication. Once you have tokens, continue with Load shifting and optimization to pull prices and drive flexible loads.

​
FAQ

PKCE protects the authorization code from interception in transit, even on a server-to-server flow. It costs nothing to add and closes a class of redirect-URI attacks.
An UNAUTHORIZED response means the customer has revoked access (or the refresh token expired). Send them through /oauth/authorize again to mint a fresh pair.
No. Refresh tokens must stay on the server. Build a thin endpoint on your side that proxies the refresh and hands the new access token to the client if needed.
Yes. Each app gets its own token pair. Revoking one doesn’t affect the others.