Syndicating Publishers
This documentation is intended for publishers that syndicate content and platforms that host syndicated content.
A publisher’s internal Customer/Institution ID needs to be shared with specific integrators during syndicated entitlement requests.
This allows platforms to share COUNTER-compliant off-platform usage data with syndicating publishers, enabling aggregation of both on-platform and off-platform usage.
Responding with Customer ID
Publishers can include their internal Customer/Institution IDs within entitlement responses specifically for approved integrators.
This is achieved by adding a customerID property within the org property in the existing entitlement response.
Example Process
-
The publisher modifies their system to include an
org.customerIDproperty in all entitlement responses specifically for “Integrator X.” -
The GetFTR API receives an entitlement request from “Integrator X” similar to the following:
{
"org": {
"ipv4": "1.2.3.4"
},
"dois": ["10.1111/1234.a.b.c"]
}- The publisher receives an entitlement request from the GetFTR API containing an HTTP Header:
X-INTEGRATOR-ID: integrator-xThis header specifies the integrator’s identifier assigned by GetFTR.
- The publisher includes the org.customerID property in the entitlement response, formatted as follows:
{
"entitlements": [
{
"doi": "10.1111/1234.a.b.c",
"source": "service_request",
"statusCode": 200,
"entitled": "yes",
"accessType": "paid",
"vor": [
{
"contentType": "text/html",
"url": "...."
}
],
"org": {
"ipv4": "1.2.3.4",
"customerID": "5555444433332222"
},
"document": "...."
}
]
}Important Considerations
The customerID property described in this document must only be returned for integrators explicitly prepared to handle it.
Many GetFTR integrators rely strictly on the documented Entitlement API Response schema. Introducing additional properties, such as customerID, without prior agreement can cause integration disruptions.