How the Attribution API credits Apple Ads taps

What the Attribution API is for#

The Attribution API is the direct, token based path linking Apple Ads taps and views to downstream app and site events you own. Where device frameworks serve partner dashboards, this API serves first party systems: your server asks Apple which tap, if any, earned the install.

Use it when you run owned analytics or server side marketing measurement and want Apple Ads credit computed from source truth rather than inferred from aggregates. The AdServices documentation defines the token request flow this API builds upon. Orient first with the Apple Ads hub if server side measurement is new to the team.

It complements rather than replaces framework postbacks: most teams run both, comparing API credit against AdAttributionKit and SKAdNetwork reads before trusting any single stream.

The 24 hour token rule#

Attribution tokens live for 24 hours, and stale tokens answer nothing. Request the token at tap time, attach it promptly and redeem it inside the TTL; anything slower returns no credit no matter how genuine the install.

This single constraint shapes the whole implementation: token caching strategies must respect expiry, retries must re-request rather than replay, and QA must simulate slow networks to prove expiry paths behave. The token lifecycle reference documents expiry and error codes precisely.

Log token age at redemption so support tickets stop guessing. Half of all mysterious unattributed installs trace back to TTL handling, not to the auction.

Tap and view windows that decide credit#

Apple Ads credits taps for 30 days and views for 1 day, and the API applies the same windows. An install inside the window can claim credit; an install outside it cannot, however persuasive the surrounding story.

Design reports around these cutoffs: compare 30 day tap cohorts against 1 day view cohorts separately instead of blending them into one install line. Our postback windows guide shows the calendar maths, and our customer type guide explains how new versus returning splits interact with windows.

When stakeholders ask why credit stops abruptly at day 31, point at the window rule before reaching for deeper theories. Boundaries this crisp are configuration, not mystery.

Pre-orders play by longer rules#

Pre-ordered apps use extended windows of 90 days for taps and 61 days for views, reflecting the long gap between announcement and release. Campaigns that build pre-launch demand need these windows or early buzz earns no measurable credit.

Plan pre-order reporting separately from launch reporting: the same tap can sit pending for weeks, then convert in a burst at release. Keep pre-order cohorts labelled through launch so the burst reads as delayed fulfilment rather than sudden genius.

Coordinate with launch inventory such as product pages and search results so the release week captures the demand pre-orders stored up.

Wiring the API into owned apps and sites#

Implementation means requesting tokens client side, passing them server side and redeeming them against Apple endpoints from your infrastructure. Keep secrets server side, validate responses before writing to analytics and store raw responses for later reconciliation.

Scope the build tightly: token plumbing first, dashboarding later. A week of raw logged responses teaches more about your traffic than a month of modelled estimates. Teams short on engineering time can lean on partner integration while the direct path matures.

Test with sandbox taps, expired tokens and out of window installs before launch. The edge cases are the implementation, and folkfox can review the plan before code freezes.

Where API credit meets console credit#

API credit and console credit should rhyme without matching exactly: same windows, different machinery, different delays. Persistent gaps point at token handling or integration bugs; small wobbles are normal plumbing noise.

Reconcile weekly using the layout in our reconciliation guide, and annotate null heavy cohorts with null rate context so framework suppression is never misread as API failure.

When the two streams agree within tolerance for a full month, promote the API feed into budget decisions. Until then, let the console pace spend and the API audit it.

Frequently asked questions#