Ingest data
Push records into a Custom Integration using the Upsert API or a webhook, reference the fields each data schema accepts, delete ingested records, and monitor ingestion on the Events tab.
Once your integration is enabled, you send it data. How you do that depends on the ingestion mode you chose: an API integration receives HTTP calls that you make, and a webhook integration receives calls that the source tool makes.
Push data with the API
Copy the Upsert Endpoint from the integration's Overview tab. It has this shape:
POST https://app.harness.io/gateway/integration/api/v1/accounts/{accountId}/integrations/{integrationId}/data/{dataKind}
Headers
Harness-Account
Yes
Your Harness account ID.
Content-Type
Yes
application/json
Request body
Records are sent in a records array. Each object is one record matching the integration's data schema:
cURL example
How updates work
The identifier field is the record's key. Pushing a record whose identifier already exists updates that record in place rather than creating a second one.
This is what lets you report progress on a long-running operation. A Jenkins pipeline can push a build with "status": "RUNNING" when it starts and push the same identifier again with "status": "SUCCESS" when it finishes, and the entity page shows one build that changed state.
Receive data with a webhook
For a webhook integration, copy the Webhook URL from the integration's Overview tab and register it in the source tool. It has this shape:
The source tool posts its own payload to this URL. Harness authenticates the request using the Auth Type you configured, then converts the payload into a record using the payload mapping on the schema fields.
You do not control the request body here, so the mapping does the work of translating it. Verify the mapping against a real payload from your tool rather than its documentation, since payload shapes often differ between event types.
Link records with entity_ref
Instead of relying on Correlation Mapping, a record can name its target entity directly with entity_ref:
Use this when the sending system genuinely knows the IDP entity reference. In most pipelines it does not, so Correlation Mapping on a value like the service name or repository URL is more practical.
Schema reference
Fields marked required cause the record to be rejected if missing. Timestamps use ISO 8601 format, for example 2026-05-26T13:55:00Z.
All schemas accept these common fields:
identifier
string
Unique record identifier from the source system. Acts as the record key for updates.
name
string
Human-readable name shown in the catalog table.
timestamp
string
Used to order records. Defaults to ingestion time if omitted.
type
string
A value you define. Records become filterable by it on the entity page.
entity_ref
string
Links the record to a catalog entity directly.
url
string
Link back to the record in the source tool. Makes the record name clickable in the catalog.
tags
object
Key-value strings for extra context.
customData
object
Free-form additional data, shown in the record details panel.
identifier
string
Yes
Unique build identifier.
name
string
Yes
Build name, such as the job or pipeline name.
timestamp
string
Yes
Build start time.
branch
string
Yes
Source branch that was built.
sha
string
Yes
Git commit SHA that triggered the build.
repositoryUrl
string
Yes
Repository URL.
status
string
No
SUCCESS, FAILED, RUNNING, ABORTED, or QUEUED.
durationInSec
integer
No
Build duration in seconds.
buildNumber
integer
No
Sequential build number.
artifact
array of strings
No
Artifacts produced by the build.
triggeredBy
string
No
Person or system that triggered the build.
service
string
No
Service identifier, commonly used for correlation.
identifier
string
Yes
Unique deployment identifier.
name
string
Yes
Deployment name, such as the pipeline name.
timestamp
string
Yes
Deployment start time.
status
string
Yes
SUCCESS, FAILED, RUNNING, ABORTED, or QUEUED.
environment
string
Yes
Target environment, such as production.
type
string
No
Deployment type, such as DEPLOYMENT or ROLLBACK.
durationInSec
integer
No
Deployment duration in seconds.
artifact
string
No
Artifact version being deployed.
triggeredBy
string
No
Person or system that triggered the deployment.
service
string
No
Service identifier, commonly used for correlation.
identifier
string
Yes
Unique incident identifier.
name
string
Yes
Incident title or summary.
status
string
No
triggered, acknowledged, or resolved.
urgency
string
No
high or low.
priority
string
No
Priority label, such as P1.
resolutionDurationInSec
integer
No
Time taken to resolve, in seconds.
assignee
object
No
Assignee details, for example { "name": "...", "email": "..." }.
timestamp
string
No
Time the incident was triggered.
service
string
No
Service identifier, commonly used for correlation.
identifier
string
Yes
Unique quality-report identifier.
name
string
Yes
Report name.
coverage
number
No
Code-coverage percentage, 0 to 100.
bugs
integer
No
Number of bugs found.
codeSmells
integer
No
Number of code smells found.
duplicatedLinesDensity
number
No
Percentage of duplicated lines.
reliabilityRating
string
No
A (best) to E (worst).
securityRating
string
No
A (best) to E (worst).
maintainabilityRating
string
No
A (best) to E (worst).
score
number
No
Overall quality score.
threshold
number
No
Minimum passing threshold for the quality metric.
status
string
No
OK, ERROR, or WARN.
type
string
No
Quality check type, for example code_coverage, unit_test, or lint.
vulnerabilities
integer
No
Number of vulnerabilities found.
technicalDebt
string
No
Technical debt estimate, for example 2h or 1d.
timestamp
string
No
Report time.
url
string
No
Link to the quality report in the source tool.
service
string
No
Service identifier, commonly used for correlation.
identifier
string
Yes
Unique issue identifier.
name
string
Yes
Issue title or vulnerability message.
timestamp
string
Yes
Time the issue was reported.
severity
string
No
CRITICAL, HIGH, MEDIUM, LOW, or INFO.
status
string
No
OPEN, CONFIRMED, RESOLVED, or CLOSED.
type
string
No
Issue type, such as VULNERABILITY.
cve
string
No
Associated CVE identifier.
rule
string
No
Rule or policy that flagged the issue.
packageVersion
string
No
Version of the affected package.
toolName
string
No
Name of the scanning tool that reported the issue.
source
string
No
Scanner or tool that found the issue.
resolution
string
No
FIXED, WONTFIX, or FALSE_POSITIVE.
url
string
No
Link back to the issue in the source tool.
service
string
No
Service identifier, commonly used for correlation.
Use the security_scan schema to record the summary output of a security scan: how many findings were found at each severity level. Use security_issues to record individual vulnerabilities.
identifier
string
Yes
Unique scan identifier.
timestamp
string
Yes
Scan time (ISO 8601).
name
string
No
Human-readable scan name.
toolName
string
No
Name of the scanning tool.
scanResult
object
No
Vulnerability counts by severity. Contains critical, high, medium, low (all integers).
target
object
No
What was scanned. Contains name, type (Repo, Container, or Other), url, and version.
url
string
No
Link to the scan report in the source tool.
service
string
No
Service identifier, commonly used for correlation.
The Custom schema accepts whatever fields you define in your JSON Schema. These fields are recognized and given special treatment when present:
identifier
string
No
Record key. If your schema omits it, records cannot be updated later.
name
string
No
Displayed as the record name.
timestamp
string
No
Used to order records.
entity_ref
string
No
Links the record to a catalog entity.
type
string
No
Makes records filterable by type.
tags
object
No
Key-value strings for extra context.
(your fields)
any
No
Any additional fields defined in your schema.
Delete ingested records
API-based integrations expose a Delete Endpoint, available on the Overview tab:
Use exactly one filter per request. Combining filters in a single call is not supported.
Monitor ingestion with the Events tab
Every Custom Integration has an Events tab that records configuration changes and ingestion activity. Use it to confirm data is arriving and to diagnose rejected records.
Filter the list with the Event Type and Status dropdowns, and select Refresh events to reload it.
Event Name
The action and its outcome, such as Integration created or Entity rejected.
Status
SUCCESS or FAILED.
Description
A summary of what happened, including the reason for failures.
Started
When the event began.
Last Updated
The most recent timestamp for the event.
Triggered By
The actor responsible, either System or the user or service account that made the call.
Events you will see include:
Integration created
The integration was created successfully.
Integration enabled
The integration is active and accepting data.
Integration updated
The configuration was changed.
Entity rejected
An incoming record was not ingested. The description gives the reason, most often a schema validation failure.
Next steps
Data that has been ingested does not appear on entity pages until you add the corresponding tab to your entity layout. Go to View data in the catalog.
Last updated
Was this helpful?