Preview clip service

1. Creating Reports and Testing Data/DDEX Partner Identifier

a) When setting up your internal reporting you must consult with your Client Success Manager to ensure that the data is aligned correctly without any errors.

We have a suggested header template to use for reporting and can provide this to you upon request. Whilst this template is not mandatory we recommend using this format so that our data and reports can be fully aligned.

b) Prior to launching we must carry out a data validation test to ensure that both the logged data on the API and the related report output is correct on both sides. Consult your Client Success Manager when you’re ready to conduct this test activity, further information is provided in the next section.

c) MassiveMusic uses DDEX Reporting, so we require a DPID (DDEX Party Identifier) for all of our partners.
When getting started with discussing reporting requirements with MassiveMusic, you will need to visit http://dpid.ddex.net/reg.php and enter the service details, you will then get a code which MassiveMusic will then associate with your partnerID in the Data Warehouse.

2. API Implementation Security For External User Accounts

When using non-MassiveMusic external user accounts your API credentials must never be stored or passed on to end user devices or client apps. They must always be kept within a trusted environment, such as a secure server. Any generated signed URLs can be sent to the end user device.

Additional API keys with restricted permissions can be provided for making non-user related API calls directly from clients.

3. Application Testing and Approval

We must test and approve your application prior to launch to ensure it is fully compliant with the agreed licenses, this is a measure that ensures you are safe to launch the application without breaching any terms. The details of the testing and approval process is twofold as follows:

a) Informal Review - you must provide us with a beta / test version Android version (apk) and an iOS version that we can test, at least 4 weeks prior to your planned launch date. This allows us enough time to conduct an initial informal check of the application to see if we can spot any compliance issues at an early stage and allow you plenty of time to address any failure points.

b) Formal Approval - you must also provide us with your final application build at least 10 days prior to your launch date so that we can conduct a formal approval process. If approval is declined we will notify you of the failure point(s) which should then be rectified before re-submitting again for the approval process.

The application(s) must be fully approved before a launch can take place.

🚧
Note
It is not permitted to make available publicly any sort of application version prior to our approval process. This includes no non-private Beta testing and no submittals to Google Play / Apple App Store.

4. Use of Content in your Application

Due to the strict requirements from the labels concerning use of their content it is not permitted to use any label content within your application, for testing or otherwise, until the labels have provided specific approval for use of their content

5. Indicating 'Explicit' Content

Where content is marked with an ‘Explicit’ flag you must reflect the same within the product title and the track title. This is usually expressed at the end of the name in brackets. eg: (Explicit)

6. Processing Takedowns

Where a label has initiated a content ‘takedown’ MassiveMusic shall remove that content from our API and Feeds.

Takedowns are indicated in the daily incremental release feeds by way of a ‘D’ command (Delete). If you have your own database of content and use the feeds you must observe the takedown immediately and remove the content from your service within 24 hours.

7. Processing Metadata Updates

Metadata updates are communicated via our daily incremental feeds. If you use the feeds you must ensure that all data updates are processed within 24 hours.

8. Partner-side Payments / Verifying User Location

If you are using your own transaction mechanism to take payments from end users then you must use the customer billing address to verify the location of the end user.

9. Logging Stream Data

You must log your streaming activity via the preview/log endpoint. These streaming logs can be sent in batches.

Note that it is required that you provide a unique identifier for each user in the userId parameter on preview/log. The user ID value can be anything that you want but must be unique to each user and provided consistently in all stream logs so that we can identify the activity of the user in our reporting for labels.

🚧
Important
We require you to retain a backup record of all your logs. The record should include a record of when the streams were initially logged to the preview/log endpoint.

10. Provide us with Launch Plan and Integration Updates

In order to make sure your launch can proceed as smoothly as possible you must provide to us full details of your launch plans at the earliest possible opportunity including any key development and launch dates.

Please allow a 4 week period prior to the launch date which we can reserve for application and report testing.

Specifically, inform your Client Success Manager with:

Planned Launch Date.
Planned Final Testing Date (at least 4 weeks prior to launch date).
Any other notable information, beta testing plans and key dates.
Updates on notable developments during your integration stage.