Frequently Asked Questions

Your endpoint must respond with a 2XX status code within 10 seconds to acknowledge the successful receipt of a request. If a different status is returned, the request will be retried up to 5 times. If it still fails, the request will be stored in an archive queue for manual re-processing for up to 14 days. In this case, you need to investigate and fix the issue with your endpoint. Once resolved, contact us to redrive the event.

During onboarding and integration, test data will be sent to your endpoint. Requests containing test data will comply with the schema, but the data itself should be disregarded. Test events can be identified by a negative integer value for the root id property.

During validation, expect the following test events:

• Maximum Release: An event including all fields as defined in the schema.
  
• Minimum Non-Takedown Release: An event with the minimal required fields. Nullable fields will be null, and non-required fields will be omitted.
  
• Explicit Takedowns: An event with only id, version, and takedown fields.

The security of your endpoint is validated by ensuring proper TLS configuration. Issues such as expired certificates, domain mismatches, or missing certificates need to be addressed for successful validation.

Your service should be prepared to handle up to 400 requests per second (RPS) during peak times, especially when receiving backfills or retrying failed events. Typically, catalog updates occur at around 1-2 RPS, but higher rates can occur depending on catalog size and peak times.

Most requests should be less than 1 MiB. However, we recommend setting your limit to 10 MiB to accommodate larger releases. There is no defined upper limit for request payload sizes.

We only support one endpoint. If you wish to change your endpoint, you can request this through your Client Success Manager.

If your endpoint goes down for maintenance or another reason, please contact your Client Success Manager.

Events are triggered at ingestion and are published as soon as content is ingested, which may be before the release or takedown dates. Events are versioned with an integer to ensure proper ordering. If you receive an event with the same version more than once, it should be reprocessed.

Yes, when there is an update, you will receive a new event containing the entire release, which should be used to overwrite the previous one.

Changes to the schema will be announced on the MassiveMusic maintenance page. It is recommended not to map directly to the schema to avoid issues caused by potential changes. To stay informed about platform updates, you can sign up for notifications on the MassiveMusic Status Page.

Requests with invalid authorisation headers should return a non-success status code (such as 401)

Managing Availability:
Both à la carte download and streaming availability will be sent in Events as it is received by licensors.

Subscription Streaming: Clearances indicate where a release can be used in any service licensed to utilise on-demand streaming rights. Where no subscription streaming clearances exist, the release is unavailable for on-demand streaming services, although it may retain streaming rights for other business models.

Ad-Supported Streaming: Clearances indicate where a release can be used in any service licensed to utilise ad-supported streaming rights. Where no ad-supported streaming clearances exist, the release is unavailable for ad-supported streaming services, although it may retain streaming rights for other business models.

À la Carte (Permanent) Download: Clearances indicate where a release can be used in any service licensed to utilise à la carte download rights (also known as permanent download rights). If a track within a release has no price, it is only available to purchase as part of the entire release. If there is a release-level Digital Booklet available (called PDF Booklet in the schema), it will only be available to purchase as part of the entire release.

Takedowns/End Dates:
Takedowns and end dates can be delivered to us in several ways. Catalogue Events will maintain the structure of this data; we do not transform it and pass it through. Common examples of how licensors will remove content include:

• A new end date is provided. Content should not be used past that date.
  
• Start and end dates are the same day.
  
• An empty release, with only the fields id, version, and takedown (see example).

You'll only receive events for licensors you have an approve licensing agreement and therefore don't need to validate on ingestion.

Artist data is contained within the release event message and therefore won't be deletable anymore.

If you experience a lack of events due to scheduled maintenance or ingestion downtime, first contact your Client Success Manager to report the issue. Additionally, sign up for notifications on the MassiveMusic Status Page to receive updates and information about platform maintenance and disruptions.

Artwork for a release can be accessed via our CDN endpoint. The URL should be constructed as follows:

Base URL: https://artwork-cdn.7static.com/static/img/sleeveart/00/000/000/
File Name: {ReleaseIdPaddedTo10Characters}_{ImageSize}.jpg

For example:
https://artwork-cdn.7static.com/static/img/sleeveart/00/000/000/0012345678_800.jpg

A list of supported image sizes can be found here.

Note: If the specified image cannot be found, a placeholder image will be returned.

This is a known limitation of REST (v1). You can avoid it by using API Gateway V2 (HTTP). See HTTP vs REST differences and Developing HTTP APIs for more details.

As a general guide, storage requirements scale with the size of the catalogue and the complexity of the metadata. For example, 2.5 million release events typically require around 42 GB of storage. Based on this, a full catalogue of approximately 16 million release events would be expected to require in the region of 350–400 GB of storage. Actual volumes will vary depending on payload size, compression, and how much historical data is retained.