# Credentials & signing

Source: https://docs.aon.pro/partner/credentials-signing

> Derived from the same AON Docs release as the source page.

Partner docs are supply-side: AON calls your endpoint, and your backend verifies the request before processing business logic. AON identifies itself with `X-AON-Key` and signs requests with `X-AON-Signature`.

Enter this step only after Portal Setup is complete and the Partner is approved. If the Partner is not approved, return to [Portal Setup](https://docs.aon.pro/partner/portal-setup) instead of issuing or configuring credentials.

> Source of truth
>
> This page explains operational responsibilities. For implementation details, use [Offer Fetch required headers](https://docs.aon.pro/partner/offer-fetch#required-headers) and the [OfferProvider API spec](https://github.com/agentoffernetwork/protocol/blob/main/v1.0/specs/offer-provider-api.md).

## Credential responsibilities

| Credential | What it does | Partner responsibility |
| --- | --- | --- |
| AppKey | Identifies the Partner account for incoming AON requests | Map the key to the right account and reject unknown keys |
| AppSecret | Shared secret used to verify HMAC signatures | Store securely, never expose to browsers, and rotate safely |

Partner Portal owns issuing, rotating, and revoking credentials. Your backend owns secure storage, runtime loading, audit logs, and request verification.

## Required request headers

Every live Offer Fetch request should be verified before business logic runs:

-   `X-AON-Key`: the AppKey AON issued to your Partner account.
-   `X-AON-Timestamp`: Unix epoch seconds used for freshness checks.
-   `X-AON-Nonce`: unique request nonce used to reduce replay risk.
-   `X-AON-Signature`: HMAC-SHA256 signature over the protocol signing string.
-   `X-AON-Test`: `true` when AON sends validation or onboarding traffic.

For the signing string and sample code, read [Sample verify implementations](https://docs.aon.pro/partner/offer-fetch#sample-verify-implementations).

## Verification order

Use one consistent verification order:

1.  Check the `X-AON-Timestamp` window.
2.  Verify `X-AON-Signature` in constant time.
3.  Check `X-AON-Nonce` against a short-TTL replay store.
4.  Parse the body only after authentication succeeds.

This mirrors the [Offer Fetch handler flow](https://docs.aon.pro/partner/offer-fetch#handler-flow) without duplicating the full implementation guide.

## Rotation and incidents

Your service should be able to load a new AppSecret without a long outage. During rotation, keep enough observability to distinguish unknown key, signature mismatch, stale timestamp, and replayed nonce failures.

If a secret is exposed, rotate it in Partner Portal and invalidate the old secret according to your incident process. Do not place AppSecret values in docs, frontend code, tickets, screenshots, or public logs.

## Credentials & Signing completion

This step is complete when the approved Partner has valid credentials, the AppSecret is in secure storage, and the backend is ready for timestamp, signature verification, and nonce checks before parsing a request. This prepares the next Offer Fetch test; it does not by itself make the Partner live.

## Related pages

-   [Partner Portal Setup](https://docs.aon.pro/partner/portal-setup)

-   [Offer Fetch](https://docs.aon.pro/partner/offer-fetch)
-   [OfferProvider API spec](https://github.com/agentoffernetwork/protocol/blob/main/v1.0/specs/offer-provider-api.md)