What data can I actually pull today?
Two endpoints. GET /v1/posts returns post-level data — every metric you'd see at the post level inside Aspire, across Instagram, TikTok, YouTube, and Pinterest. GET /v1/members returns the same metrics rolled up to the creator level, with per-network and per-post-type breakdowns. Both support filtering by date range, network, project, group, member, post type, and mention source.
How do we set it up?
In Aspire, go to Settings → Integrations → Aspire API, click Create API Key, name it, set permissions, set an expiration, and copy the key. One thing to flag: the key is only visible once at creation, so it has to be copied right away.
What about permissions?
Keys are scoped. Today's scopes include read:social (post and member analytics), read:affiliate, read:member, read:payment, and read:product-fulfillment. Most brands only need read:social for reporting use cases. A key issued for one scope can't access endpoints outside it.
What do I need to make a request?
Two things — the API key and your client ID. The client ID is in the URL of your Aspire workspace, right after /client/. There's a test request tool inside the documentation so you can run a call and see the JSON response before your engineers touch it.
Can we filter what comes back?
Yes — heavily. Filter by date range, network (Instagram, TikTok, YouTube, Pinterest), project, group, member, post type, mention source (brand-initiated, creator-submitted, or auto-discovered via social listening), and post status (live, expired, deleted). You can also choose between lifetime metrics and date-range-scoped metrics depending on the reporting question.
Can we sort and paginate?
Yes. Sort by impressions, engagements, engagement rate, TMV, view time, and a few others. Pagination is offset/limit, up to 500 records per page.
Are there rate limits?
Yes. Standard rate limiting applies — if a request gets throttled, the API returns a 429 and the client should back off and retry. Most reporting use cases stay well under the limit because they're scheduled pulls, not real-time queries. Engineering can confirm specifics in the docs.
What's the security model?
Three things to know. Keys are only shown once at creation — Aspire doesn't store them visibly after that. Keys can have a TTL (time to live) — 30d, 1y, or no expiration — and we recommend setting one and rotating regularly. The recommendation is one key per integration, scoped to the minimum permissions it needs, so anything can be revoked without breaking the rest. Revocation is a single API call or a click in Settings.
Who's this actually for? Our team isn't technical.
Two patterns. If you have a BI or analytics team, they're the audience — they'll plug it in and the influencer marketing team just sees better dashboards. If you don't, your agency or implementation partner can set it up, or our support team can help your team get started.
Is there a sandbox?
There's a test request tool inside the documentation that lets you run live calls and see the response format before writing any code. That's usually enough for engineering to scope the integration.
How is this different from our existing integrations (Shopify, etc.)?
Existing integrations are pre-built for specific use cases. The API is the open version — for teams that want to build something custom, or pipe data into a tool we don't have a native integration with.
What about affiliate, payment, or product fulfillment data?
The scopes exist (read:affiliate, read:payment, read:product-fulfillment), so the foundation is there. Confirm endpoint availability with PMM before promising specific affiliate or payment endpoints to a prospect — the social analytics endpoints are where the immediate value sits.