Feeds, schedules and push in the integration hub
How DPP Shield fetches a source on a schedule, which authentication each feed supports, and how your system can push records instead.
DPP Shield editorial team · Updated:
A mapping receives data in one of three ways: you upload a file, DPP Shield fetches a feed over HTTPS or SFTP on a schedule, or your system pushes records to the mapping's push endpoint with a push token. All three use the same preview, matching and versioning.
Three ways in
Upload suits a one-off file. A feed suits a source DPP Shield can reach and authenticate to on its own; it runs manually, hourly or daily. Push suits a source that cannot be fetched - a system that needs signed requests or a session login, or an integration platform that already produces the export - and lets that system decide when data is sent.
Feed connection options
Credentials are stored encrypted and never shown again. They are cleared if the feed address moves to another host, so a changed address cannot send your secret elsewhere. Feeds only reach public addresses.
Supported options
- HTTPS GET, or POST with a body for GraphQL, OData or SuiteQL queries.
- No authentication, a bearer token, basic credentials, or an API key in a header you name.
- OAuth 2.0 with the client-credentials or password grant, client authentication by basic header or in the body, and an optional scope; a token is requested for each run.
- SFTP with a password or a private key, against a pinned host key: Test feed shows the key the server presents, to compare with the fingerprint your server administrator gives you.
- In a POST body, write {{credential}} where the secret goes; it is then stored encrypted rather than in the body.
Limits
One run reads up to 5,000 records and a source of up to 10 MB; a mapping holds up to 200 rules and a value map up to 100 entries. Split larger sources by product family, or push them in batches.
Push records from your system
A push token can only push to its own mapping; it cannot read anything. Treat it like a password and keep it in your integration platform's secret store.
- On the mapping, open Feed and push and issue a push token. It starts with dpm_ and is shown once; issuing a new one replaces it.
- Send POST https://api.dppshield.com/api/v1/public/integrations/<mapping id>/push with the header Authorization: Bearer <push token>.
- Put the records in the body exactly as the mapping reads them: CSV with Content-Type text/csv, XML with application/xml, or JSON with application/json. CSV and XML bodies may be up to 10 MB.
- Add ?dryRun=true to the address to get the preview without writing anything.
- Read the response: it is the run summary - records, updated, created, unchanged, unmatched and errors - and the run also appears in the mapping's history with the trigger push.
When a run does not do what you expected
Unmatched records mean the key differs between the systems - leading zeros, spaces or another identifier altogether. Errors name the record and the field. Run a preview after any change to the source, and remember that an empty source value never blanks a field.