ProvelyNo. HubSpot CRM API returns a 201 response with a deal object when it accepts the request. The deal then holds one of 2 states. Provely proves created, in_stage and logged as separate promises.
| Fact | Value |
|---|---|
| Skill version | 0.1.0 |
| Publisher | Built and signed by Provely. |
| Certification | Provisional (score 49 of 100) |
| Last conformance run | 2026-09-05T12:00:00Z: 46 of 46 cases passed, 0 critical false VERIFIED |
| Provider API versions | 2026-03 |
| Default provider API version | 2026-03 |
| Compiled | 2026-09-05T12:00:00Z by compiler 0.1.0 |
| Manifest hash | 51408ddccc5bfcdd |
| Manifest hash check | the document hashes to the value the manifest states |
| Signature | valid, key provely-skill-2026-09, trusted by this build |
What does this page prove?
| Claim | Proven by | Evidence | Status |
|---|---|---|---|
| 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.created | E2 + E3 | proven |
| 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_stage | E2 + E3 | proven |
| 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.logged | E2 | proven |
| An outcome outside HubSpot CRM API, such as a bank credit or a person who read a message | not proven | no E5 channel | not proven |
The meaning of the in_pipeline_stage state of hubspot.deal | not proven | no source states it | not proven |
| The agent report that the action worked | never counts | E0 | not 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.
| Level | Contract | Promise | Evidence | Certification |
|---|---|---|---|---|
created | hubspot.deal.created v1.0.0 | 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. | E2 + E3 | Provisional |
in_stage | hubspot.deal.in_stage v1.0.0 | 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. | E2 + E3 | Provisional |
logged | hubspot.engagement.logged v1.0.0 | 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. | E2 | Provisional |
What is the HubSpot CRM API lifecycle?
Which states can a hubspot.deal be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
in_pipeline_stage | unknown | UNVERIFIABLE | The deal sits in a stage of a pipeline. The published pages enumerate no stage identifier and state no meaning for one, because a portal defines its own stages. | hubspot.docs.deals |
archived | terminal neutral | FAILED | An archive removed the deal from the pipeline. The member archived is true, and the member archivedAt states the time. | hubspot.docs.deals |
Which states can a hubspot.note be in?
| State | Class | Verdict | Meaning | Source |
|---|---|---|---|---|
logged | transitional | PENDING | The note exists on the timeline. The member archived is false. HubSpot states no further state for a note. | hubspot.docs.notes |
archived | terminal neutral | FAILED | An archive removed the note. The member archived is true. | hubspot.docs.notes |
How does Provely tie the evidence to this exact operation?
A matching state that already existed must not verify. Every contract names the correlation keys that bind the evidence to the operation, and the idempotency key that stops a duplicate side effect.
| Strategy | Assurance | Keys | Required | Window |
|---|---|---|---|---|
resource_id | strong | deal_id from $action.result.id | yes | none |
fingerprint | weak | dealname from $input.dealname; pipeline from $input.pipeline | no | 600000 ms |
resource_id | strong | note_id from $action.result.id | yes | none |
fingerprint | weak | deal_id from $input.deal_id; hs_timestamp from $input.hs_timestamp | no | 600000 ms |
In words
- E0 agent assertion: never sufficient.
- E1 action response: the provider acknowledged the request.
- E2 provider readback: the runtime read the resource back.
- E3 provider event: the provider reported the change.
- E4 independent system: a system outside the action path agrees.
- E5 external outcome: the result is observable in the world.
Which evidence channels does the skill read?
The runtime prefers the channel that is more independent from the action path. Read the evidence level definition. An acknowledgement from HubSpot CRM API is E1 and never terminal success.
| Channel | Level | Independence | Verifier | Deterministic | Typical latency |
|---|---|---|---|---|---|
deal_action_response | E1 | same response | action_result | yes | not stated |
deal_creation_events | E3 | provider event | webhook | no | 5000 ms |
deal_creation_events_in_account | E3 | provider event | webhook | no | 5000 ms |
deal_readback | E2 | provider readback | http | yes | 400 ms |
engagement_creation_events_in_account | E3 | provider event | webhook | no | 5000 ms |
engagement_readback | E2 | provider readback | http | yes | 400 ms |
Which ways can a HubSpot CRM API action look done and not be?
| Contract | Case | Rule | Verdict |
|---|---|---|---|
| hubspot.deal.created | wrong subject | The deal sits in a different pipeline than the intent named. | CONTRADICTED |
| hubspot.deal.created | wrong subject | The deal carries a different name than the intent named. | CONTRADICTED |
| hubspot.deal.created | wrong amount | The deal carries a different amount than the intent stated. | CONTRADICTED |
| hubspot.deal.created | pre existing state | The deal is older than the operation. It proves nothing. | CONTRADICTED |
| hubspot.deal.created | duplicate side effect | HubSpot created more than one deal in the account since the operation started. Do not retry. | CONTRADICTED |
| hubspot.deal.created | observed state | The deal is archived. The record left the pipeline. Ask a person. | CONTRADICTED |
| hubspot.deal.in_stage | wrong subject | The deal sits in a different pipeline than the intent named. | CONTRADICTED |
| hubspot.deal.in_stage | wrong subject | The deal carries a different name than the intent named. | CONTRADICTED |
| hubspot.deal.in_stage | wrong amount | The deal carries a different amount than the intent stated. | CONTRADICTED |
| hubspot.deal.in_stage | pre existing state | The deal is older than the operation. It proves nothing. | CONTRADICTED |
| hubspot.deal.in_stage | duplicate side effect | HubSpot created more than one deal in the account since the operation started. Do not retry. | CONTRADICTED |
| hubspot.deal.in_stage | wrong subject | The deal sits in a different stage than the intent named. HubSpot sets the stage from the create request, so no wait changes it. Stop and ask a person. | CONTRADICTED |
| hubspot.deal.in_stage | observed state | The deal is archived. The record left the pipeline. Ask a person. | CONTRADICTED |
| hubspot.engagement.logged | wrong subject | The engagement is associated with a different deal than the intent named. | CONTRADICTED |
| hubspot.engagement.logged | partial completion | HubSpot wrote the note and associated it with no deal. The engagement is not on the timeline of the deal. Ask a person. | CONTRADICTED |
| hubspot.engagement.logged | pre existing state | The note is older than the operation. It proves nothing. | CONTRADICTED |
| hubspot.engagement.logged | duplicate side effect | HubSpot created more than one record in the account since the operation started. Do not retry. | CONTRADICTED |
| hubspot.engagement.logged | observed state | The note is archived. It is not on the timeline of the deal. Ask a person. | CONTRADICTED |
What did the last conformance run show?
| Dimension | Score | Maximum |
|---|---|---|
| Documentation | 14 | 20 |
| Schema alignment | 11.45 | 15 |
| Lifecycle certainty | 15 | 20 |
| Evidence strength | 12 | 20 |
| Causal correlation | 15 | 15 |
| Sandbox conformance | 10 | 10 |
| Raw score | 77.45 | 100 |
| Score after the caps | 49 | 100 |
The raw score is 77.45. 3 hard caps apply, so the score is 49 and the level is Provisional.
| Reason | Highest score it allows |
|---|---|
| A lifecycle state has unknown semantics. The compiler cannot prove the end state. | 49 |
| 14 uncertainty records are open. The lowest cap is 49. | 49 |
| 3 mandatory cases are missing. Example: hubspot.deal.created:terminal_failure. | 74 |
| Contract | Raw score | Score after the caps | Certification |
|---|---|---|---|
hubspot.deal.created | 77.5 | 49 | Provisional |
hubspot.deal.in_stage | 78.13 | 49 | Provisional |
hubspot.engagement.logged | 78.5 | 49 | Provisional |
The weakest contract is hubspot.deal.created. It scores 49 and 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 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.
| Case class | Passed | Total |
|---|---|---|
| duplicate side effect | 3 | 3 |
| error after execution | 3 | 3 |
| error before execution | 3 | 3 |
| evidence unavailable | 3 | 3 |
| pre existing state | 3 | 3 |
| stale readback | 3 | 3 |
| still transitional | 3 | 3 |
| terminal success | 4 | 4 |
| timeout after commit | 3 | 3 |
| version mismatch | 3 | 3 |
| webhook duplicate | 3 | 3 |
| webhook out of order | 3 | 3 |
| wrong amount | 2 | 2 |
| wrong subject | 4 | 4 |
| wrong terminal state | 3 | 3 |
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. A lifecycle state has unknown semantics. The compiler cannot prove the end state. 14 uncertainty records are open. The lowest cap is 49. 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.
| Source | Kind | Retrieved | Excerpt |
|---|---|---|---|
| hubspot.docs.deals | docs | 2026-09-08 | authored |
| hubspot.docs.notes | docs | 2026-09-08 | authored |
| hubspot.docs.versions | docs | 2026-09-08 | authored |
| hubspot.docs.webhooks | docs | 2026-09-08 | authored |
| hubspot.events | event sample | 2026-09-08 | authored |
| hubspot.openapi | openapi | 2026-09-08 | authored |
How do I verify a HubSpot CRM API action?
Verify a HubSpot CRM API action with Provely
- Begin the operation.Call
beginwith the contracthubspot.deal.createdand the input. Keep the operation id. - Make the HubSpot CRM API call you make today.Send the request with the correlation metadata that
beginreturned. - Submit the acknowledgement.Call
action_resultwith the HubSpot CRM API response. This is evidence level E1. It is not completion. - Verify.Call
verify. The runtime readsdeal_action_response,deal_creation_events,deal_creation_events_in_account,deal_readback,engagement_creation_events_in_accountandengagement_readbackand evaluates the contract. - 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.