Sense Talent Labs · OpenAPI Overlay 1.0.0

API Evangelist enhancements for the Sense API

8 actions 8 updates update
Generated by API Evangelist Written by API Evangelist tooling for Sense Talent Labs's API. It is a proposal applied on top of the contract, not a document Sense Talent Labs publishes.
View Overlay File View on GitHub Overlay Specification

What the actions change

versioncontacttermsOfServicex-token-url-productionx-token-lifetime-secondsx-token-caching-requiredx-token-caching-notex-scope-model

Targets 5

$.info
$.servers
$.components.securitySchemes.sense_authentication.flows.clientCredentials
$.components.securitySchemes.sense_authentication.flows.clientCredentials.scopes
$.paths.*.post

OpenAPI Overlay

Raw ↑
overlay: 1.0.0
info:
  title: API Evangelist enhancements for the Sense API
  version: 1.0.0
x-provenance:
  generated: '2026-08-26'
  method: generated
  source: openapi/sense-talent-labs-sense-api-openapi.json
  extends: openapi/sense-talent-labs-sense-api-openapi.json
  note: 'Non-destructive enhancements only. The original document is preserved verbatim in
    openapi/_original/. Every value added here is sourced from Sense''s own published
    documentation at https://developer.sensehq.com/ — nothing is invented.'
actions:
- target: $.info
  description: 'The published document declares an empty info.version. Set it to the URI path
    version the API actually serves and which the docs use throughout.'
  update:
    version: v1
- target: $.info
  description: Add the contact channel published on https://www.sensehq.com/security and the terms
    published in the site footer.
  update:
    contact:
      name: Sense Talent Labs, Inc.
      url: https://www.sensehq.com/support
      email: security@sensehq.com
    termsOfService: https://www.sensehq.com/terms-and-conditions
- target: $.servers
  description: >-
    THE MOST CONSEQUENTIAL CORRECTION IN THIS OVERLAY. The published document ships exactly one
    server, https://partner-api.us-stage.sensehq.co, which is a STAGING host. Every prose example
    in the same document — the sync-order list and all three Python samples in info.description —
    uses the production base https://partner-api.sensehq.com/v1. A client generated from the spec
    as published points at staging and will not reach production. This action adds production as
    the first server and relabels the existing entry as staging, without removing it.
  update:
  - url: https://partner-api.sensehq.com/v1
    description: Production. Sourced from the sync-order list and the sample code in the
      document's own info.description.
  - url: https://partner-api.us-stage.sensehq.co
    description: Staging. The only server declared in the published document. Not documented as a
      customer-accessible sandbox and no credentials for it are published.
- target: $.components.securitySchemes.sense_authentication.flows.clientCredentials
  description: 'The declared tokenUrl is the staging authorization server. Production is
    https://partner-auth.sensehq.com/oauth2/token, used in all three sample-code blocks.'
  update:
    x-token-url-production: https://partner-auth.sensehq.com/oauth2/token
    x-token-lifetime-seconds: 300
    x-token-caching-required: true
    x-token-caching-note: Clients MUST cache and reuse the access token until expiry, reading the
      lifetime from expires_in rather than hardcoding it. Unnecessary token requests may lead to
      rate limiting or deactivation.
- target: $.components.securitySchemes.sense_authentication.flows.clientCredentials.scopes
  description: Annotate the placeholder scope so a generator does not emit "N/A" as a real scope
    value.
  update:
    x-scope-model: none
    x-authorization-note: The Sense API has no scope vocabulary. A credential is bound to one
      agency tenant and carries full read and write access to every entity type.
- target: $.paths.*.post
  description: Record the batch limits that govern every write. maxItems is already declared in the
    contract; the compressed payload ceiling and the 413 trigger are documented only in prose.
  update:
    x-batch-max-items: 500
    x-batch-max-payload: 256 KB after compression
    x-batch-exceeded-status: 413
    x-write-semantics: upsert
    x-upsert-note: Whole-entity replace keyed on the caller-supplied id. Omitted fields are
      cleared, not preserved. Use PATCH for partial updates.
    x-idempotent: true
    x-idempotency-mechanism: upsert-on-natural-key
- target: $.paths.*.post
  description: Record the accept-then-enqueue semantics. A 201 confirms the batch was enqueued,
    not that it was persisted or is visible.
  update:
    x-processing: async
    x-visibility-delay: approximately 30 minutes for Change Event processes
    x-read-after-write-consistent: false
- target: $.info
  description: 'Record the gaps an integrator must plan around. None of these responses is declared
    anywhere in the published contract even though every operation is authenticated.'
  update:
    x-undeclared-responses:
    - status: 401
      note: no unauthorized response is declared on any operation despite bearer auth being
        required everywhere
    - status: 403
      note: no forbidden response is declared
    - status: 429
      note: no rate-limit response is declared, though the docs warn that excessive token requests
        may cause rate limiting or deactivation
    - status: 5xx
      note: no server-error response is declared on any operation
    x-no-required-fields: Every entity schema omits a `required` array and marks every property
      nullable, so the contract cannot express a valid request. The prose instruction "Take care
      that all fields are provided" carries that requirement instead.
    x-delete-semantics: 'Soft delete only. There is no DELETE method in the contract; deletion is
      expressed by sending the entity with is_deleted = true.'
    x-sync-order:
    - internal-users
    - candidates
    - client-contacts
    - companies
    - job-orders
    - submissions
    - placements
    - leads
    - certifications
    - appointments