Apollo

The Corma and Apollo integration keeps Apollo seats, credits and permissions in line with your sales team. Apollo.io calls itself an AI GTM system that combines data, intelligence and execution in one loop, and sales teams use its prospecting and engagement tools, including sequences. Apollo bills by seat while its data credits are pooled across the team, so both seats and credit use need an owner.

Key takeaways

• Apollo bills by seat, all seats on an account share one plan, and changes to the plan or seat count apply at once.
• Apollo credits are pooled across the whole team, and admins can set per-user credit caps.
• Deactivating an Apollo user does not change the subscription, so the seat count has to be reduced separately.
• An Apollo API key identifies the workspace, not a person, and every API-key request acts as the workspace's longest-standing active admin.

What does an Apollo departure leave behind?

Apollo separates deactivation from billing. Its help center says deactivating a user does not delete their data, and asks admins to reassign the user's contacts, accounts, sequences, deals, tasks and workflows. Scheduled emails are marked Not sent unless the admin unlinks the user's mailbox and reassigns them to another mailbox. Because deactivation does not change the subscription, the seat stays paid for: an admin can give it to a new user or lower the seat count, and the lower price applies from the next plan term.

API keys need a different kind of attention. An Apollo API key identifies the workspace, not a person: every request made with it acts as the longest-standing active admin, who also owns the records it creates. Keys are scoped to selected endpoints by default, while a master key works on every endpoint, including the one that lists users. Offboarding an early admin therefore also changes who API activity is attributed to.

How Corma governs Apollo

• Seats matched to reps: Corma flags Apollo seats held by deactivated or inactive users, so the seat count can come down before renewal, a core step of software license optimization.
• Offboarding in the right order: a leaver workflow in the IT Workflow Builder asks the manager to reassign the rep's records and sequences before the account is deactivated, then asks an admin to unlink their mailbox and reassign their scheduled emails.
• Permission profiles under review: admin profiles and anyone allowed to manage users go into automated access reviews.
• Joiners through requests: new reps ask for Apollo in the self-service app store, and a manager approves before a seat is assigned.

Frequently asked questions

Does Apollo support SSO and SCIM?

Apollo supports SAML SSO, both SP- and IdP-initiated, with setup guides for Google, Microsoft, Microsoft Entra ID and Okta, and once SSO is on, users can only log in through it. The pricing page mentions SSO in the Custom plan description. SCIM provisioning is documented for Okta: removing a user in Okta deactivates them in Apollo. See how SCIM and SAML differ.

How does Corma connect to Apollo?

Through Apollo's API, which Apollo places on Custom plans, or through Corma's browser-based agents in Apollo's team settings. Corma governs the rest of your sales stack the same way, such as Salesforce.

Where is Corma data hosted?

Corma runs on AWS, with web servers and databases in data centers inside the European Union. Data is encrypted in transit and at rest, and Corma is ISO/IEC 27001:2022 certified.

Want to see which Apollo seats are still paid for reps who left? Book a Corma demo.