How do you share one market data API subscription with a whole team instead of buying a separate plan for every developer? On SiftingIO the honest answer used to be a workaround. Either everyone passed around a single API key, which ruins auditing and turns key rotation into a group event, or every person bought their own plan and finance reconciled five invoices for the same data. The new Team feature removes the workaround: one subscription can now be shared with teammates. One person owns the plan and pays for it, everyone else joins by email invite and works under it.
This post covers the mechanics: how seats are counted per tier, how invites and joining work, what members can and can't do, and what happens to API keys when someone leaves.
How sharing one subscription works#
The mechanics start with ownership. The person who owns the plan is the team owner, and the owner's tier sets the seat count:
| Tier | Seats |
|---|---|
| Free | 1 |
| Builder | 3 |
| Pro | 10 |
| Ultra | 25 |
| Enterprise | Unlimited |
The owner invites people by email. The invited person clicks the link in the email, signs in or registers with that address, and joins the team. That's the whole flow. There's no key hand-off and no plan checkout on the member's side.
One detail matters for planning: each pending invite occupies a seat until it's accepted. Seats are a budget for members plus outstanding invitations, so on a Builder plan with 3 seats, unanswered invites can block a new teammate from being added even though nobody new has actually joined yet. The owner can cancel a pending invite to free its seat.
What members get#
A member automatically gets the owner's plan: the same markets, the same limits, and the same API-key allowance, with no subscription of their own. If the owner holds Pro access for US stocks and crypto, every member works with Pro-level access to those markets.
Members hold their own API keys, so a teammate who accepted an invite five minutes ago can create a key and start pulling data:
curl --compressed -H "X-API-Key: $SIFTING_KEY" \
"https://api.sifting.io/v1/hist/stocks/AAPL/bars?interval=1d"
Streaming works the same way. Connect to wss://stream.sifting.io/ws/v1?key=$SIFTING_KEY and subscribe:
{ "op": "subscribe", "product": "cex", "symbols": ["BTCUSD", "ETHUSD"] }
Nothing about the requests changes because a team is involved. The key authenticates, the entitlements come from the owner's plan, and the responses look exactly as they do for a solo account.
The separation of duties is deliberate. Members cannot see billing and cannot manage the team. The owner is the only one who can rename the team, remove members, cancel pending invites, and see the whole team's API usage in one place. That last part is the operational win: instead of asking each developer what their scripts consumed this month, the owner reads one usage view that covers everyone.
What happens when someone leaves#
Offboarding is strict, and it's worth knowing before you wire production services to a teammate's key. When a member leaves the team or is removed, their API keys are revoked and their account drops back to the Free plan.
Revoked means revoked: any script, cron job, or dashboard authenticating with that person's key stops working. The right pattern follows from that. Keys for shared or production workloads should belong to the owner's account, or at least to an account that isn't about to roll off the project. Personal keys are for personal work: research notebooks, local experiments, one-off pulls. When a teammate departs, their personal keys dying is then harmless, and nothing customer-facing notices.
The Free fallback is also worth flagging to departing teammates. Their account still exists and still works, but at Free-tier quotas, which are a fraction of a Builder or Pro allowance. A backfill job that ran comfortably under the team's plan will hit rate limits quickly on Free.
Common pitfalls#
Pending invites eat seats. An invite sent to an address someone rarely checks will sit there holding a seat indefinitely. If adding a new member fails on a plan that should have room, look for stale pending invites and cancel them before assuming you need a higher tier.
The invite is tied to the address it was sent to. The invited person has to sign in or register with that exact email address to join. Sending an invite to a teammate's personal address when their existing SiftingIO account lives under their work address leads to a confusing dead end. Invite the address they'll actually authenticate with.
Removal breaks keys downstream. Removing a member as part of offboarding revokes their keys in the same stroke. Audit which jobs run under that person's keys before removing them, and migrate anything shared to a key that survives the removal. Doing it in the other order means finding out from a failing dashboard.
One plan, one invoice, one usage view#
For a development team, a quant desk, or a fintech product team where several people need the same data access, the arithmetic is straightforward. A Pro subscription carries 10 seats, so a whole desk works under one plan instead of a stack of individually purchased ones. One invoice replaces a pile of expense reports, and one usage view replaces per-person guesswork about who consumed what. The short version: one person pays and manages, everyone on the team works under that plan.
Seat counts follow the tier ladder above; plan details are on the pricing page.
