No. HubSpot CRM API returns a success response when it accepts the request. Provely proves created, in_stage and logged as separate promises.

Skill facts from the signed manifest.
FactValue
Skill version0.1.0
PublisherBuilt and signed by Provely.
CertificationProvisional
Last conformance run2026-09-05T12:00:00Z: 46 of 46 cases passed, 0 critical false VERIFIED
Provider API versions2026-03
Default provider API version2026-03
Compiled2026-09-05
Manifest hash51408ddccc5bfcdd
Manifest hash checkthe document hashes to the value the manifest states
Signaturevalid, key provely-skill-2026-09, trusted by this build

What does this page prove?

ClaimProven byEvidenceStatus
The record exists with the intended name in the intended pipeline. It does not prove the stage that the person asked for. Read the level in_stage for that.hubspot.deal.createdE2 + E3proven
A created deal is not a deal in the right stage. HubSpot sets the stage from the create request, so another stage is a wrong value.hubspot.deal.in_stageE2 + E3proven
A note that exists is not a note on the deal. The level reads the note and the association to the deal that the person named.hubspot.engagement.loggedE2proven
An outcome outside HubSpot CRM API, such as a bank credit or a person who read a messagenot provenno E5 channelnot proven
The meaning of a HubSpot CRM API state that no source statesnot provenno source states itnot proven
The agent report that the action workednever countsE0not proven

Which completion levels does the HubSpot CRM API skill expose?

Each level is one promise with one contract. An agent picks the level that matches the promise it makes. It cannot upgrade a level. Read the completion level definition.

LevelContractPromiseEvidenceCertification
createdhubspot.deal.created v1.0.0The record exists with the intended name in the intended pipeline. It does not prove the stage that the person asked for. Read the level in_stage for that.E2 + E3Provisional
in_stagehubspot.deal.in_stage v1.0.0A created deal is not a deal in the right stage. HubSpot sets the stage from the create request, so another stage is a wrong value.E2 + E3Provisional
loggedhubspot.engagement.logged v1.0.0A note that exists is not a note on the deal. The level reads the note and the association to the deal that the person named.E2Provisional

Which ways can a HubSpot CRM API action look done and not be?

ContractCaseVerdict
hubspot.deal.createdduplicate side effectCONTRADICTED
hubspot.deal.createdpre existing stateCONTRADICTED
hubspot.deal.createdwrong amountCONTRADICTED
hubspot.deal.createdwrong subjectCONTRADICTED
hubspot.deal.in_stageduplicate side effectCONTRADICTED
hubspot.deal.in_stagepre existing stateCONTRADICTED
hubspot.deal.in_stagewrong amountCONTRADICTED
hubspot.deal.in_stagewrong subjectCONTRADICTED
hubspot.engagement.loggedduplicate side effectCONTRADICTED
hubspot.engagement.loggedpartial completionCONTRADICTED
hubspot.engagement.loggedpre existing stateCONTRADICTED
hubspot.engagement.loggedwrong subjectCONTRADICTED

What did the last conformance run show?

The last conformance run on 2026-09-05T12:00:00Z passed 46 of 46 cases with 0 critical false VERIFIED. One critical false VERIFIED rejects a skill.

The certification of each contract.
ContractCertification
hubspot.deal.createdProvisional
hubspot.deal.in_stageProvisional
hubspot.engagement.loggedProvisional

The weakest contract is hubspot.deal.created. It reaches Provisional. The package level is Provisional, because a package level never rises above its weakest contract. Read the level of the contract you use.

The conformance result by case class.
Case classPassedTotal
duplicate side effect33
error after execution33
error before execution33
evidence unavailable33
pre existing state33
stale readback33
still transitional33
terminal success44
timeout after commit33
version mismatch33
webhook duplicate33
webhook out of order33
wrong amount22
wrong subject44
wrong terminal state33

The conformance artifact digest is c9281160c47982e2. The harness signs the run, so a reader can check that these numbers come from that run.

What remains uncertain?

The level is Provisional because of it. Provely does not guess a rule that a source does not state.

Where do these facts come from?

Every claim above cites a source assertion in the skill provenance. The compiler records the source, its hash, and the retrieval date. A page never states a provider rule without one.

SourceKindRetrievedExcerpt
hubspot.docs.dealsdocs2026-09-08authored
hubspot.docs.notesdocs2026-09-08authored
hubspot.docs.versionsdocs2026-09-08authored
hubspot.docs.webhooksdocs2026-09-08authored
hubspot.eventsevent sample2026-09-08authored
hubspot.openapiopenapi2026-09-08authored

How do I verify a HubSpot CRM API action?

Verify a HubSpot CRM API action with Provely

  1. Begin the operation.Call begin with the contract hubspot.deal.created and the input. Keep the operation id.
  2. Make the HubSpot CRM API call you make today.Send the request with the correlation metadata that begin returned.
  3. Submit the acknowledgement.Call action_result with the HubSpot CRM API response. This is evidence level E1. It is not completion.
  4. Verify.Call verify. The runtime reads the evidence that the contract names, from HubSpot CRM API and not from the agent, and evaluates the contract.
  5. Report the verdict exactly as returned.VERIFIED comes with a signed receipt. PENDING comes with the operation id. CONTRADICTED and UNVERIFIABLE are not success.

Questions developers ask

Does the created level prove the logged level?

No. The record exists with the intended name in the intended pipeline. It does not prove the stage that the person asked for. Read the level in_stage for that. A note that exists is not a note on the deal. The level reads the note and the association to the deal that the person named. Use hubspot.engagement.logged to prove logged.

Which HubSpot CRM API API versions does the skill support?

2026-03. An operation on another version returns UNVERIFIABLE with the reason version_unsupported. The runtime never guesses.

Does Provely need write access to HubSpot CRM API?

No. The agent keeps its write key. The verifier reads with a separate read-only credential where HubSpot CRM API permits it, and it never shares that credential with the agent.