Recently, I was asked to help a client gain better visibility into the mobile applications they publish through Apple's App Store. Their goal was straightforward: automatically load application deployment information from Apple App Store Connect into ServiceNow so those applications could be tracked alongside the rest of their enterprise software portfolio.
Like many integrations, the biggest challenge wasn't retrieving the data. The biggest challenge was getting authenticated.
The Challenge
Apple App Store Connect APIs require authentication using a JWT (JSON Web Token) signed with an ES256 elliptic curve signature.
On paper this sounds simple enough. ServiceNow includes support for both OAuth and JWT-based authentication mechanisms, so my first thought was to leverage the platform's native capabilities.
Unfortunately, I quickly discovered a limitation.
While ServiceNow supports JWT token generation for common scenarios, it does not natively support creation of the specific ES256-signed tokens required by Apple App Store Connect. This meant the standard OAuth and JWT tooling available within the platform could not be used to generate a valid token for Apple's APIs.
After exploring several options, I decided to move token generation outside of the ServiceNow entirely.
The Solution Architecture
Rather than forcing the platform to do something it was not designed to do, I leveraged an existing component many organizations already have available: the MID Server.
The solution consists of three primary components:
- A PowerShell script running on the MID Server
- A Flow Designer Action responsible for invoking the script
- ServiceNow Script Include that handles API communication and data loading
Integration flow
Script Include | Flow Action | MID Server | Apple API | Import Set | Transform Map |
The overall flow works like this:
- ServiceNow requests an authentication token.
- Flow Designer executes a PowerShell script on the MID Server.
- The PowerShell script generates an ES256 JWT token using Apple's private key.
- The token is returned to ServiceNow.
- ServiceNow stores and reuses the token until expiration.
- The Script Include calls App Store Connect APIs and loads application information into a staging table.
- Transform Maps move the data into the target application inventory tables.
This approach allowed me to keep all Apple-specific authentication logic isolated while still leveraging native ServiceNow capabilities for the actual integration processing.
Generating the JWT on the MID Server
The heart of the solution is a PowerShell script that constructs and signs the JWT required by Apple.
The script:
- Builds the JWT header with the ES256 algorithm
- Builds the JWT payload using the Apple Issuer ID
- Uses the Apple private key to sign the token
- Returns a structured JSON response back to ServiceNow
Because the execution occurs on the MID Server, I could leverage PowerShell cryptographic libraries that support ES256 signing without introducing custom Java libraries or unsupported platform modifications.
Wrapping the Integration in a Script Include
Once token generation was solved, the rest of the integration became much more straightforward.
I created a reusable Script Include that manages interaction with the Apple App Store Connect APIs.
The Script Include is responsible for:
- Obtaining and caching authentication tokens
- Calling App Store Connect REST endpoints
- Handling pagination
- Retrieving application metadata
- Retrieving release information
- Gathering territory availability information
- Loading records into an import set staging table
The Script Include stores tokens and only requests a new one when necessary. This reduces both API calls and MID Server activity.
Importing Applications Through a Staging Table
Rather than writing directly into production application tables, I chose to use a traditional import set pattern.
The integration loads application records into a custom import set table and then leverages Transform Maps to process the data into the final destination.
This approach provides several benefits:
- Simplified troubleshooting
- Visibility into imported records
- Reusability of transform logic
- Easier testing and validation
- Alignment with standard ServiceNow data loading patterns
The staging table captures information such as:
- Application Name
- Bundle ID
- Store Identifier
- Available Territories
- Version
- App Store Status
- Store URL
Only applications that are actively available for distribution are loaded into the import set.
Figure 1. Custom Import Set Data Source invoking the Script Include to retrieve Apple App Store application data.
Lessons Learned
Use the Right Tool for the Job
When I realized ServiceNow could not natively generate the ES256 tokens Apple required, I stopped trying to force a platform-only solution. Leveraging PowerShell on the MID Server ended up being cleaner and easier to support.
Isolate Authentication Logic
Keeping the JWT generation separate from the App Store API logic resulted in a much cleaner architecture and made troubleshooting significantly easier.
Leverage Import Sets
Even though I could have written directly into target tables, using a staging table provided a much better operational experience.
Cache Tokens
Token generation is expensive compared to token reuse. Caching reduced unnecessary processing and improved overall performance.
Resources
If you'd like to explore the solution further, the source files used in this implementation are included as attachments to this blog:
Resource | File |
ServiceNow Script Include | AppStoreConnect_ScriptInclude.txt |
PowerShell token generator | GetAppleJWTToken_PS1.txt |
Have you run into similar challenges integrating third-party platforms that require authentication mechanisms not natively supported by ServiceNow? I’d love to hear how you approached the problem.
