Credentials & signing

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 instead of issuing or configuring credentials.

Source of truth

This page explains operational responsibilities. For implementation details, use Offer Fetch required headers and the OfferProvider API spec.

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.

Verification order

Use one consistent verification order:

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

This mirrors the 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.