Apple Developer Enterprise Program with Monopam

An Apple Developer Enterprise Program account is managed by Monopam the same way a standard account is, with one thing to get right first: the Enterprise Program is a separate Apple API, with its own address and its own kind of key. This page covers what differs. Everything else is in Certificates on Apple Developer.

The difference in one line	An Enterprise key cannot talk to App Store Connect, and an App Store Connect key cannot talk to the Enterprise API. Pick the program on the issuer and the rest follows
API address	`api.enterprise.developer.apple.com` (standard accounts: `api.appstoreconnect.apple.com`)
Where the key is made	developer.apple.com → Users and Access → Integrations
What Monopam manages there	Signing certificates, App IDs, devices and provisioning profiles, exactly as on a standard account
What is not there	The App Store side of things: no Apple Pay certificate types, no G2 Developer ID types, no App Store distribution

1. Get API access, then a key

Enterprise API access is not on by default:

The Account Holder signs in at developer.apple.com, goes to Users and Access → Integrations, and requests access to the Apple Developer Enterprise Program API (the terms are accepted once).
An Account Holder or Admin then generates a key. Keep the Issuer ID, the Key ID and the .p8 file; Apple lets the .p8 be downloaded once.

Apple states these keys are unique to the Enterprise Program and cannot be used for other Apple services. That is why the wrong pairing fails the way it does, and it fails on every call rather than on some of them.

2. Add the issuer in Monopam

Certificates → Issuers → Add Issuer → Apple Developer, and set:

Field	Value
Program	`Apple Developer Enterprise Program`
Issuer ID, Key ID, API key (.p8)	From the Integrations screen above
Certificate type	What this issuer issues. For an account you are taking over rather than issuing in, choose Any type: it imports and renews whatever the account already holds
Membership expires on	From Apple Developer → Membership details. Apple exposes this in no API, and an expired enterprise membership invalidates every certificate the account issued

Test connection answers Connected to the Apple Developer Enterprise Program: 7 certificate(s) visible. on an Enterprise issuer. If it answers HTTP 401 Provide a properly configured and signed bearer token, the Program field is the first thing to check: the key is being sent to the other API.

Open the firewall to the enterprise host before testing: Apple code signing: network requirements.

3. What you can issue there

Apple offers a shorter list of certificate types on the Enterprise Program:

Available	`DEVELOPMENT`, `DISTRIBUTION`, `IOS_DEVELOPMENT`, `IOS_DISTRIBUTION`, `MAC_APP_DEVELOPMENT`, `MAC_APP_DISTRIBUTION`, `MAC_INSTALLER_DISTRIBUTION`, `DEVELOPER_ID_APPLICATION`, `DEVELOPER_ID_KEXT`, `PASS_TYPE_ID`, `PASS_TYPE_ID_WITH_NFC`
Not available	The four Apple Pay types and the G2 Developer ID variants

Distribution here means in-house distribution: apps signed for your own employees rather than for the App Store. Everything else about issuance works as on a standard account: Monopam makes the key and the signing request, Apple signs, and the private key stays in Monopam.

4. Provisioning profiles and devices

In-house profiles use the iOS In-House (Enterprise) profile type in Create via Apple. Development and ad-hoc profiles still take device UDIDs, and a device Apple does not know yet is registered on the account automatically.

The rest is identical to a standard account: profiles are imported or created, their expiry is watched, and a certificate renewal regenerates the profiles bound to it with a new UUID.

5. Watching the account itself

Certificates → Issuers opens with an Apple accounts panel: one card per Apple account, saying which program it belongs to, which key it holds, how long the membership has left, and how much depends on it (certificates, how many of those carry a private key, profiles, App IDs, and how many certificates expire within thirty days). Check connection on the card asks Apple whether the stored key still works, which is the one test that separates a lapsed membership or a revoked key from a network problem.

An account whose membership date has not been filled in says so on the card. That date is the only part of an Apple account Monopam cannot discover for itself.

6. When the membership has expired

An expired enterprise membership is not a build problem, it is a fleet problem: apps already installed on employees' devices stop launching, because the certificate that signed them is no longer trusted. Order of work:

The account holder renews at developer.apple.com. Nobody else can: Apple's renewal and its reminders go to that person only, which is why the contact details are worth checking once a year.
Check the account in Monopam (the card's Check connection). Once the membership is active again, the same key starts working; no certificate or profile has to be re-created in Monopam.
Re-sign and re-distribute whatever was signed with a certificate Apple invalidated. Monopam can tell you what that is: the account card gives the counts and the inventory's Issued through filter lists the certificates themselves.
Set Membership expires on to the new date on the issuer. The reminders start over from the widest threshold.

If the membership cannot be renewed in time, the honest answer is that there is no technical workaround: Apple's trust in those certificates is what expired.

7. The things that bite on an enterprise account

The membership is the single point of failure. Fill Membership expires on so Monopam warns in advance on the same schedule as certificates, and keep the account holder's contact details current, because Apple's own reminders go only to them.
Few people, one account. Enterprise accounts usually have a very small number of admins; losing the one person who holds the key is the common failure. Keep the API key in Monopam (stored encrypted, never shown again) rather than on somebody's laptop.
Rotating the key. When an admin leaves, or a key is suspected of having leaked: create a new key in Users and Access → Integrations, edit the Apple issuer in Monopam and paste the new .p8 with its Key ID (leaving the field blank keeps the old one), press Check connection, and only then revoke the old key at Apple. Nothing else has to change: the certificates, profiles and App IDs already tracked are unaffected.
Distribution certificates are shared and limited. Check what the account already holds (Import from Apple on the issuer) before issuing another one.
Revocation is manual. Monopam does not revoke at Apple; revoke in the portal and then archive the row here.
Removing an account from Monopam deletes nothing at Apple: the issuer goes, and the certificates it issued stay in the inventory with no renewal path until another issuer for that account is added.

8. Status of this integration

Monopam's Enterprise support is the same code path as the standard one, differing only in the address it calls and what the signed token says it is for. Both were taken from Apple's Enterprise Program API documentation, and the behaviour is covered by automated tests.

It has not yet been exercised against a live Enterprise account, because we hold none. The quickest way to confirm it in your environment: add the issuer with Program set to Enterprise, press Test connection, and open Import from Apple on the issuer. Both are read-only and change nothing on the account, and the API key can be revoked in the portal immediately afterwards if you prefer.

Monopam Certificate Manager.