CoodraDocs

Authorization

Connector access belongs on rails.

POS and commerce connectors touch operational data, so authorization is backend-owned, signed, scoped, encrypted, and guided.

Authorization flow

  1. 1

    Start from Coodra

    Coodra starts the connector flow through the backend integration endpoint.

  2. 2

    Bind state

    Authorization state is signed, short-lived, and bound to provider and tenant context.

  3. 3

    Validate callback

    The provider returns to the backend callback, where the response is checked before connection state changes.

  4. 4

    Protect credentials

    Tokens are encrypted before storage. Secrets never move into frontend code or public docs.

  5. 5

    Verify usefulness

    Guided onboarding verifies fields, scopes, data quality, and the retailer workflow before relying on the connector operationally.

Credential boundary

Connector credentials belong in backend-owned storage, encrypted at rest, and scoped to the retailer context that authorized them. They should never be copied into frontend code, docs, screenshots, or chat.

Before a connector becomes self-serve

Requirement
Why it matters
Signed state
Prevents a callback from being accepted outside its intended flow.
Refresh handling
Keeps long-running connections reliable without asking the user to reconnect constantly.
Revocation handling
Lets access be removed cleanly when a retailer disconnects.
Field verification
Confirms the connector exposes the data Coodra needs for useful recommendations.