Skip to main content

App Store Connect Data Source

App Store Connect is Apple's developer portal for managing iOS, macOS, tvOS, watchOS, and visionOS apps. Follow the instructions below to create a new data flow that ingests data from an App Store Connect source in Nexla.
appstore_api.png

App Store Connect

Create a New Data Flow​

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

  2. Select the App Store Connect connector tile from the list of available connectors. Then, select the credential that will be used to connect to the App Store Connect instance, and click Next; or, create a new App Store Connect credential for use in this flow.

  3. In Nexla, App Store Connect data sources can be created using pre-built endpoint templates, which expedite source setup for common App Store Connect endpoints. Each template is designed specifically for the corresponding App Store Connect endpoint, making source configuration easy and efficient.
    • To configure this source using a template, follow the instructions in Configure Using a Template.

    App Store Connect sources can also be configured manually, allowing you to ingest data from App Store Connect endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this source manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common App Store Connect endpoints. Each template is designed specifically for the corresponding App Store Connect endpoint, making data source setup easy and efficient.

Endpoint Settings​

  • Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

    List Builds

    This endpoint returns a paginated list of all builds across your team, with extensive filtering and sparse-fieldset support. Use it to sync TestFlight and App Store build history into a warehouse, build release dashboards, or monitor build processing state.

    • All filter, sort, fields, and limit parameters on this template are optional. Leave them blank to return the default response, or set specific values to narrow and shape the result.
    • To restrict results to a specific app, enter the app's Apple ID in the Filter by App field. App IDs can be obtained from the App Store Connect UI or from the /v1/apps endpoint.
    • To filter by build state, set Filter by Processing State (PROCESSING, FAILED, INVALID, or VALID), Filter by Beta Review State, or Filter by Expiration (true or false).
    • To filter by version, enter the build version string in Filter by Version, or the pre-release version string in Filter by Pre-Release Version Number. Use Filter by Platform (IOS, MAC_OS, TV_OS, VISION_OS, or WATCH_OS) to scope by platform.
    • To narrow by relationship, enter IDs in Filter by App Store Version, Filter by Beta Groups, Filter by Pre-Release Version ID, or Filter by ID.
    • Control the response shape by entering comma-separated field lists in the various Fields parameters (for example, Builds Fields, App Store Versions Fields), and by entering comma-separated relationship names in Include Related Resources (for example, app,preReleaseVersion,buildBetaDetails).
    • Use Sort Order to order the result set (for example, -uploadedDate for newest builds first). Use Limit (max 200) to control page size, and the related-resource limit fields (Beta Build Localizations Limit, Icons Limit, Individual Testers Limit) to cap included relationships per build.

    Apple's App Store Connect API paginates using cursor-based links returned in the response's links.next field. For complete reference, see List Builds.

    Get Build

    This endpoint returns a single build resource by ID, with rich sparse-fieldset and relationship-include support. Use it to drill into a specific build identified by a parent flow (for example, after List Builds), or to fetch the latest details for a known build ID.

    • Enter the build's identifier in the Id field. Build IDs can be obtained from the List Builds endpoint or from any relationship that references a build.
    • Use Include Related Resources to request related resources in a single call (comma-separated, for example app,buildBetaDetails,betaAppReviewSubmission,preReleaseVersion,appStoreVersion).
    • Use the sparse-fieldset parameters (Builds Fields, Apps Fields, App Store Versions Fields, Pre-Release Versions Fields, Build Beta Details Fields, Build Icons Fields, Beta App Review Submissions Fields, Encryption Declarations Fields, Performance Power Metrics Fields, Diagnostic Signatures Fields, Beta Testers Fields, Beta Build Localizations Fields) to request only the attributes you need on the build and each included relationship.
    • Use the limit parameters (Beta Build Localizations Limit, Icons Limit, Individual Testers Limit) to cap the number of items returned for the corresponding related relationships.

    When all sparse-fieldset and include parameters are left blank, App Store Connect returns the build's default attribute set. For the full attribute and relationship reference, see Read Build Information.

    Get App Store Version

    This endpoint retrieves a specific App Store version (the release record for a particular version string and platform of an app), with optional sparse fieldsets and relationship includes. Use it to inspect the metadata, build link, localizations, age-rating declarations, and submission state for a release in progress or already-published version.

    • Enter the App Store version's identifier in the Version ID field. Version IDs can be obtained from the /v1/apps/{'{id}'}/appStoreVersions endpoint or from any relationship that references an App Store version.
    • Use Include Related Resources to request related resources in a single call (comma-separated, for example build,appStoreVersionLocalizations,ageRatingDeclaration,appStoreReviewDetail,appStoreVersionSubmission,appStoreVersionPhasedRelease).
    • Use the sparse-fieldset parameters (App Store Version Fields, Build Fields, Localization Fields, Age Rating Declaration Fields, Review Detail Fields, Submission Fields, Phased Release Fields, IDFA Declaration Fields, Routing App Coverage Fields) to restrict the attributes returned.
    • Use Localization Limit to cap the number of included localizations returned with the version.

    Create App Store Version

    This endpoint creates a new App Store version for an app. It is exposed as a source template (rather than a destination) so that it can be chained inside a Nexla flow — for example, to create a new version before patching its localizations or attaching a build.

    • Enter the JSON request body in the Version Data field. The value must be the contents of the data envelope expected by App Store Connect — including type: "appStoreVersions", attributes.versionString and attributes.platform (IOS, MAC_OS, TV_OS, VISION_OS, or WATCH_OS), and a relationships.app entry pointing at the target app.
    • The endpoint wraps the value in a top-level data property automatically, so the field should contain the inner object only.

    For the complete request schema and the list of optional attributes (for example, copyright, releaseType, earliestReleaseDate), see Create an App Store Version.

    Update App Store Version

    This endpoint updates the attributes of an existing App Store version — useful for changing the version string, copyright, release type, or attaching a different build.

    • Enter the existing version's identifier in the Version ID field.
    • Enter the JSON request body in the Version Data field. The value must be the data envelope contents, including type: "appStoreVersions", the matching id, and the attributes (and/or relationships) to change.

    Only fields present in the request body are modified; omitted fields are left untouched.

    Update App Info

    This endpoint updates a single appInfo resource — the editable container for an app's primary and secondary categories and other top-level metadata that is editable for the version under review.

    • Enter the appInfo resource's identifier in the Id field. App Info IDs can be retrieved through the app's appInfos relationship.
    • Enter the JSON request body in the App Info Data field. The value must be the data envelope contents — typically relationships.primaryCategory, relationships.primaryCategoryV1, or relationships.secondaryCategory set to the corresponding appCategories resource.

    List App Categories

    This endpoint returns the list of App Store categories available for app metadata (Games, Productivity, etc.), with optional platform and parent filters. Use it to populate a lookup table of valid category IDs for Update App Info.

    • To restrict to a specific platform, enter the platform code (IOS, MAC_OS, TV_OS, VISION_OS, or WATCH_OS) in Filter by Platforms.
    • Use Filter by Parent Category with true to return only subcategories, or false to return only top-level categories.
    • Use Include Related Resources to include parent and/or subcategories, and Subcategories Limit to cap the number of subcategories returned per parent.
    • Use Fields to Include to control which category fields are returned, and Limit (max 200) to control page size.

    List App Encryption Declarations

    This endpoint returns the encryption declarations associated with your team's apps, optionally filtered by app, build, or platform. Use it to audit which apps and builds have a valid declaration on file.

    • To restrict results, enter values in Filter by App (an app ID), Filter by Builds (a comma-separated list of build IDs), or Filter by Platform (IOS, MAC_OS, TV_OS, VISION_OS, or WATCH_OS).
    • Use Include Related Resources with app or builds to return related resources inline.
    • Use Encryption Declaration Fields and App Fields to control which fields are returned, and Limit (max 200) to control page size.

    List App Previews for Preview Set

    This endpoint returns all app previews (video assets) in a specific preview set. Use it to audit which device families have completed preview uploads for a given App Store version localization.

    • Enter the parent preview set's identifier in the Preview Set Id field. Preview Set IDs can be obtained through the App Store version localization's appPreviewSets relationship.
    • Use Fields[Apppreviews] and Fields[Apppreviewsets] to restrict the returned attributes, and Include to inline related resources (for example, appPreviewSet).
    • Use Limit to control page size.

    Commit an App Screenshot Reservation

    Screenshot uploads to App Store Connect use a three-step asset reservation flow: reserve, upload bytes to the returned upload operations, and commit. This endpoint performs the final commit step by sending uploaded: true and the file's sourceFileChecksum to the screenshot resource.

    • Enter the reserved screenshot's identifier in the Screenshot ID field. The ID is returned from the Make an App Screenshot Asset Reservation destination endpoint.
    • Enter the commit JSON envelope in the Screenshot Commit Data field — typically type: "appScreenshots", the same id, and attributes with uploaded: true and sourceFileChecksum set to the MD5 hash of the uploaded file.

    For the full asset-upload flow (reserve, PUT to uploadOperations, commit), see Uploading assets to App Store Connect.

    Create Bundle ID

    This endpoint registers a new bundle ID resource on your developer account — the persistent identifier that links an app's binary, profiles, and certificates. Exposed as a source template so it can be chained into Nexla flows that provision identifiers programmatically.

    • Enter the JSON request body in the Data field. The value must be the data envelope contents — type: "bundleIds" and attributes containing identifier (the reverse-DNS bundle ID), name, platform (IOS, MAC_OS, or UNIVERSAL), and an optional seedId.

    Get Bundle ID

    This endpoint retrieves a single bundle ID resource with optional related capabilities, profiles, and apps.

    • Enter the bundle ID's resource identifier (the API-internal identifier, not the reverse-DNS string) in the Id field.
    • Use Include Related Resources with bundleIdCapabilities, profiles, and/or app to return related resources inline.
    • Use the sparse-fieldset parameters (Bundle ID Fields, Capability Fields, Profile Fields, App Fields) and the limit parameters (Capability Limit, Profile Limit) to shape the response.

    Update Bundle ID

    This endpoint updates the attributes of an existing bundle ID resource — most commonly to rename the bundle ID display name.

    • Enter the bundle ID's resource identifier in the Id field.
    • Enter the JSON request body in the Data field. The value must be the data envelope contents — type: "bundleIds", the matching id, and attributes.name set to the new display name.

    Get Certificate

    This endpoint returns a single signing certificate resource (development, distribution, push, or pass type) by ID.

    • Enter the certificate's resource identifier in the Id field.
    • Use Certificate Fields with a comma-separated list of attributes (for example, certificateContent,displayName,expirationDate,certificateType,serialNumber) to limit the response payload.

    List Certificates

    This endpoint returns a paginated list of all certificates on the developer account, with filtering and sorting. Use it to audit upcoming certificate expirations or inventory by type.

    • To restrict the result set, enter values in Certificate Type (for example IOS_DEVELOPMENT, IOS_DISTRIBUTION, MAC_APP_DEVELOPMENT, DEVELOPER_ID_APPLICATION), Display Name, Serial Number, or Certificate ID.
    • Use Sort Order to order results (prefix the field with - for descending — for example, -expirationDate for certificates closest to expiration first).
    • Use Certificate Fields to limit returned attributes, and Result Limit (max 200) to control page size.

    List Pass Type IDs for a Certificate

    This endpoint returns the pass type IDs (Apple Wallet identifiers) associated with a specific certificate. Use it to map Wallet signing certificates to the pass types they sign.

    • Enter the certificate's resource identifier in the Certificate ID field.

    List All Certificates for a Pass Type ID

    This endpoint returns all certificates associated with a specific Wallet pass type ID — the inverse of List Pass Type IDs for a Certificate.

    • Enter the pass type ID's resource identifier in the Pass Type ID field.

    List Certificates for a Merchant ID

    This endpoint returns the Apple Pay merchant identity certificates associated with a specific merchant ID. Use it to audit which certificates are currently bound to each Apple Pay merchant ID.

    • Enter the merchant ID's resource identifier in the Merchant ID field.

    List All Certificates in a Profile

    This endpoint returns the certificate resources linked to a specific provisioning profile.

    • Enter the provisioning profile's resource identifier in the Profile ID field.

    List All Devices in a Profile

    This endpoint returns the registered test devices linked to a specific provisioning profile.

    • Enter the provisioning profile's resource identifier in the Profile ID field.

    Read the Bundle ID in a Profile

    This endpoint returns the single bundle ID resource that a provisioning profile is bound to. Use it to map provisioning profiles back to their bundle IDs when auditing the provisioning state of an app.

    • Enter the provisioning profile's resource identifier in the Profile ID field.

    List Analytics Report Requests for an App

    This endpoint returns the analytics report requests that have been created for a specific app. Each request is the parent record for a stream of reports the team has opted into through the App Store Connect Analytics API.

    • Enter the app's Apple ID in the App ID field.
    • To restrict the result set, set Access Type to ONGOING (for recurring report streams) or ONE_TIME_SNAPSHOT (for a single-day backfill request).
    • Use Result Limit to control page size.

    Each app can have at most one ONGOING analytics report request. The recurring report files are then exposed through the request's reports relationship. For the full Analytics API model, see Downloading analytics reports.

    Read an Analytics Report Request

    This endpoint returns a single analytics report request by ID. Use it to confirm the access type and stoppedDueToInactivity status of a request before consuming its reports.

    • Enter the analytics report request's identifier in the Report Request ID field. Request IDs can be obtained from the List Analytics Report Requests for an App endpoint or from the response of the Create an Analytics Report Request destination.

    Delete an Analytics Report Request

    This endpoint cancels and removes an analytics report request. Use it to stop a previously created ONGOING request when the team no longer needs the recurring reports.

    • Enter the analytics report request's identifier in the Report Request ID field.

    Deletion is permanent — the underlying historical reports remain accessible only as long as Apple retains them, so download anything still needed before deleting the request.

    Get Power and Performance Metrics for an App

    This endpoint returns aggregated Xcode-style power and performance metrics for the most recent App Store version of an app — including launch time, hangs, memory, disk usage, and battery. The response uses Apple's application/vnd.apple.xcode-metrics+json media type.

    • Enter the app's Apple ID in the App ID field.
    • To narrow the data set, use Device Type (for example, IPHONE, IPAD, MAC), Platform (IOS, MAC_OS, TV_OS, WATCH_OS), and/or Metric Type (DISK, HANG, LAUNCH, MEMORY, BATTERY).

    Because the response is the Xcode metrics media type, this endpoint is best paired with a Path to Data in Response that targets the inner productData array (see Configure Manually).

    Download Sales and Trends Reports

    This endpoint downloads Sales and Trends reports for the given vendor, frequency, and report type/subtype. The response is a gzipped TSV file rather than JSON.

    • Enter your vendor number from Payments and Financial Reports in the Vendor Number field. Vendor numbers are typically 8 digits.
    • Set Frequency to DAILY, WEEKLY, MONTHLY, or YEARLY.
    • Set Report Type to one of SALES, PRE_ORDER, NEWSSTAND, SUBSCRIPTION, SUBSCRIPTION_EVENT, SUBSCRIBER, or SUBSCRIPTION_OFFER_CODE_REDEMPTION.
    • Set Report Sub Type to SUMMARY, DETAILED, or OPT_IN as required by the selected report type.
    • Enter the report period in Report Date. The format depends on frequency: YYYY-MM-DD for DAILY, YYYY-MM-DD (any day in the week) for WEEKLY, YYYY-MM for MONTHLY, or YYYY for YEARLY.
    • For report types and subtypes that require a version (for example, SUBSCRIBER), enter the version in Report Version (for example, 1_3).

    Date/Time macros (see Configure Manually) can be used in the Report Date field to schedule rolling daily, weekly, or monthly downloads — for example, {'{now-1}'} with a Day time unit and YYYY-MM-DD date format. For the full sales report reference, see Download Sales and Trends Reports.

    Download Finance Reports

    This endpoint downloads finance reports for a given fiscal period and region — the official payout-level records that Apple publishes monthly. The response is a gzipped report file.

    • Enter your vendor number in the Vendor Number field.
    • Set Region Code to a two-letter ISO region code, or ZZ for the consolidated report across all regions.
    • Enter the fiscal period in Report Date in YYYY-MM format. The period follows Apple's fiscal calendar rather than the standard calendar month.
    • Set Report Type to FINANCIAL (the default, summary by SKU) or FINANCE_DETAIL (line-item detail).

    Finance reports are not published in real time — Apple makes them available roughly 30 days after the end of each fiscal month. For the full region list and field reference, see Download Finance Reports.

    List Users

    This endpoint returns a paginated list of users in the App Store Connect account, with optional filters by role, username, and visible apps. Use it to feed a user-access audit or to keep an external identity store in sync.

    • To restrict the result set, set Filter by Roles (comma-separated, for example ADMIN,DEVELOPER,FINANCE), Filter by Username, or Filter by Visible Apps (comma-separated app IDs).
    • Use Sort Order to order results (prefix with - for descending — for example, -lastName).
    • Use Users Fields and Apps Fields to restrict the returned attributes, and Include Related Resources with visibleApps to inline the apps each user can access.
    • Use Results Limit (max 200) to control page size, and Visible Apps Limit to cap the number of related apps per user.

    List User Invitations

    This endpoint returns the team's pending user invitations — users who have been invited but have not yet completed sign-up. Use it to audit outstanding invites for renewal or revocation.

    • No configuration is required for this endpoint beyond selecting it. All pending invitations on the team are returned automatically.

    List All Apps Visible to an Invited User

    This endpoint returns the apps that a pending user invitation will be able to see once accepted. Use it to validate an outstanding invitation's app-level scope before it is accepted.

    • Enter the user invitation's identifier in the User Invitation ID field. Invitation IDs can be obtained from the List User Invitations endpoint.

    Read the Deliveries for a Webhook

    This endpoint returns the delivery records for a specific App Store Connect webhook subscription — each record describes one attempted delivery to your endpoint, including timestamps, HTTP status, and retry state. Use it to monitor webhook health or build a delivery audit log.

    • Enter the webhook's identifier in the Webhook ID field. Webhook IDs can be obtained through the /v1/webhooks endpoint or from the App Store Connect Webhooks UI.

Endpoint Testing​

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually​

App Store Connect data sources can be manually configured to ingest data from any valid App Store Connect API endpoint. Manual configuration provides maximum flexibility for accessing endpoints not covered by pre-built templates — for example, beta groups, TestFlight testers, in-app purchases, customer reviews, or any newly released endpoint.

With manual configuration, you can also create more complex App Store Connect sources, such as sources that use chained API calls — for example, listing apps and then fetching builds, App Store versions, or analytics report instances for each.

API Method​

  1. To manually configure this source, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the App Store Connect API from the Method pulldown menu. Most App Store Connect read endpoints use GET:

    • GET: For retrieving resources, lists, or relationships
    • POST: For creating resources (typically used in destinations, but available here for chained source calls)
    • PATCH: For partial updates to resources
    • DELETE: For removing resources

API Endpoint URL​

  1. Enter the URL of the App Store Connect API endpoint from which this source will fetch data in the Set API URL field. All App Store Connect API URLs use the base https://api.appstoreconnect.apple.com/v1/ followed by the resource path (for example, https://api.appstoreconnect.apple.com/v1/apps).

Ensure the API endpoint URL is correct and accessible with your current credentials. You can test the endpoint using the Test button after configuring the URL.

Date/Time Macros (API URL)​

Optional

Optionally, the API URL can be customized using macros—all macros added to the API URL will be converted into values when Nexla executes the API call. Macros are dynamic placeholders that allow you to create flexible API endpoints that adapt to different time periods. They are particularly useful for App Store Connect endpoints that take a filter[reportDate], filter[date], or similar date filter — most notably the Sales and Trends and Finance report endpoints.

Macros are particularly useful for APIs that require date ranges or other dynamic values that change between data ingestion runs. For example, use {now-1} with a Day time unit and a YYYY-MM-DD date format to always fetch yesterday's daily sales report.

  1. To add a macro, type { at the appropriate position in the API URL (within the Set API URL field), and select the desired macro from the dropdown list.

    • {now} – The current datetime

    • {now-1} – The datetime one time unit before the current datetime

    • {now+1} – The datetime one time unit after the current datetime

    • custom – Datetime macros can reference any number of time units before or after the current datetime—for example, enter (now-4) to indicate the datetime four time units before the current datetime

  2. Select the format that will be applied to datetime macros from the Date Format for Date/Time Macro pulldown menu. App Store Connect typically expects YYYY-MM-DD for daily report dates, YYYY-MM for monthly/finance report dates, and YYYY for yearly report dates, so the selected format must match the endpoint being called.

  3. Select the datetime unit that will be used to perform mathematical operations in the included macro(s) from the Time Unit for Operations pulldown menu—for example, for the macro {now-1}, when Day is selected, {now-1} will be converted to the datetime one day before the current datetime.

Lookup-Based Macros (API URL)​

Optional

Column values from existing lookups can also be included as macros in the API URL. Lookup-based macros allow you to reference data from previously configured data sources or lookups, enabling dynamic API endpoints that adapt based on existing data. For App Store Connect, this is useful when you have a Nexla dataset of app IDs, build IDs, certificate IDs, or version IDs and want to fetch the related resource for each.

Lookup-based macros are useful when you need to create App Store Connect URLs that reference specific IDs from another data source — for example, fetching the latest build details for every app ID returned by a /v1/apps source.

  1. To include a lookup column value macro, select the relevant lookup from the Add Lookups to Supported Macros pulldown menu.

  2. Type { at the appropriate position in the API URL, and select the lookup column-based macro from the dropdown list. Lookup-based macros are automatically populated into the macro list when a lookup is selected in the Add Lookups to Supported Macros pulldown menu.

Path to Data​

Optional

If only a subset of the data returned by an App Store Connect endpoint is needed, you can designate the part(s) of the response that should be included in the Nexset(s) by specifying the path to the relevant data within the response.

App Store Connect follows the JSON:API specification: list endpoints (such as /v1/builds or /v1/users) return an array of resources under the top-level data key, so the path to data is $.data[*]. Single-resource endpoints (such as /v1/builds/{'{id}'}) return a single object under data, so the path is $.data.

Path to Data is essential when API responses have nested structures. Without specifying the correct path, Nexla might not be able to properly parse and organize your data into usable records.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (for example, $.data[*] to access every element of the top-level data array, or $.data for a single-object response).
    Path to Data Example:

    For an App Store Connect list endpoint (such as GET /v1/builds), enter $.data[*] as the path to data. For a single-resource endpoint (such as GET /v1/builds/{'{id}'}), enter $.data. For Sales/Finance report endpoints that return a gzipped TSV file, no path is needed — the response is parsed as a delimited file.

Autogenerate Path Suggestions​

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata​

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. App Store Connect responses typically include sibling top-level keys (such as meta.paging.total, links.self, links.next, and included) alongside the data array, and this setting can be used to preserve any of those values with each record.

A common pattern is to set Path to Metadata in Response to $.meta to capture the paging information returned with each list call, or to $.links to capture cursor URLs for downstream auditing.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

    You do not need to include any headers already present in the credentials. The Authorization: Bearer <jwt> header is added automatically based on your App Store Connect credential. The most common header to add here is Accept: application/vnd.apple.xcode-metrics+json when calling the perfPowerMetrics endpoint, or Accept: application/a-gzip when downloading salesReports or financeReports.

Endpoint Testing​

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source​

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new App Store Connect data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.