Developer API: automate posting with API keys

Some posts shouldn't need a human in the app. A new product lands in your store and you want it announced. A blog post publishes and you want it cross-posted. A nightly job pulls last week's numbers into a report. For all of that, you want to talk to SocialPatra from your own code, not click through screens.

That's what API keys are for. You create a key, give it exactly the permissions it needs, and use it to drive posting and scheduling programmatically. This guide walks through creating a key, scoping it sensibly, and the limits worth knowing before you build on it.

Creating an API key

API keys live in your workspace settings, under API key management. A key belongs to one workspace, so it can only act on that workspace's accounts and data. If you're an agency running a client per workspace, you create a separate key per client and a leak in one never touches another.

1. Open the workspace you want the key to act in.
2. Go to API key management in settings.
3. Give the key a clear name, like "Zapier - product launches".
4. Pick the scopes (permissions) it needs.
5. Optionally set an expiry, a request rate limit, and allowed origins or IPs.
6. Create the key and copy it right away.

The full secret key is shown only once, at creation. After that you'll only ever see a short prefix that identifies which key it is. Save it in your secrets manager or your automation tool's credential store the moment you create it. If you lose it, you rotate: create a new key and delete the old one.

Scopes: give each key only what it needs

Every key carries a list of scopes. A scope is one permission, split into reading and writing so you can hand out the minimum. A reporting job should read analytics and nothing else. A publishing bot needs to write posts but has no business managing connections.

These are the scopes you'll reach for most:

• posts:read and posts:write — view, create, and schedule posts (with posts:delete and posts:approve when you need them)
• media:upload — upload images and video, required for posts that carry media
• queue:read and queue:write — view and manage the publishing queue
• schedule:read and schedule:write — view and set posting time windows
• analytics:read — pull post and account analytics for reporting
• connections:read — see which accounts are connected (with connections:write to manage them)
• feeds:read and feeds:write — view and manage RSS feed automation
• ai:generate — use AI generation from your integration

A good default for a publishing automation is posts:write plus media:upload, and connections:read if your code needs to look up which accounts exist. Add analytics:read only on the key that does reporting.

Expiry, rate limits, and access control

When you create a key you can lock it down further so a forgotten or leaked key does limited damage.

• Expiry — set the number of days until the key expires (anywhere up to several years), or leave it open-ended for a key that should never expire. Short-lived keys are a good habit for temporary integrations.
• Rate limits — cap requests per minute and per day. The defaults are 60 per minute and 10,000 per day, which is plenty for most posting workflows.
• Allowed origins — restrict which web origins can use the key from a browser.
• Allowed IPs — restrict the key to specific IP addresses, so it only works from your server.

You can also add a description to remind future-you what a key is for. "Used for nightly analytics export" beats a name you'll have forgotten in three months.

Using a key in practice

Once you have a key, you authenticate your requests with it and call the same actions you'd do by hand: create a post, schedule it for a time, attach media, or read back analytics. Because the key is workspace-scoped, you don't pass a client ID around; the key already knows which workspace it belongs to.

A few real automations people build:

• A creator wires their newsletter platform so every send also drafts a cross-platform post.
• An online store auto-announces new products to Instagram and Facebook when they go live.
• An agency runs a nightly job that pulls each client's weekly numbers into a shared report.
• A no-code tool like a workflow automation app triggers a post when a row is added to a sheet.

Keeping keys safe

• Treat a key like a password. Store it in a secrets manager, never in a public repo.
• Use one key per integration so you can revoke just that one if it's compromised.
• Give each key the narrowest scopes that still let it do its job.
• Rotate keys periodically: create a new one, switch your integration over, delete the old.
• Restrict by IP for server-side keys that always call from the same place.

FAQ

I lost my key. Can I see it again?

No. The full key is shown once at creation; after that only a short prefix is visible. If you've lost it, create a new key and delete the old one.

Can one key post to multiple clients?

No. A key is tied to a single workspace. For multiple clients you create a key in each client's workspace, which keeps them isolated.

What happens if I hit the rate limit?

Requests beyond the per-minute or per-day cap are throttled. The defaults (60/minute, 10,000/day) suit most posting workflows; you can set your own when you create the key.

Do I need a separate key for reading analytics?

Not strictly, but it's good practice. Give your reporting job a key with only analytics:read so it can't accidentally publish anything.

Ready to automate your posting? Start free during early access, create your first scoped API key, and wire SocialPatra into your own workflow.