# EffectGuard HubSpot note-once developer pilot Service: https://effectguard-x402-experiment.onrender.com Page: https://effectguard-x402-experiment.onrender.com/agent Kit: https://effectguard-x402-experiment.onrender.com/agent/hubspot.zip Fit: cooperating Python agents/workers can repeat a HubSpot note for one form submission. They need one shared guard account and source-assigned event IDs. This is an opt-in adapter, not a CRM plugin that a discovered API installs for you. The first downloadable pilot is limited to a dedicated test contact. A local unique key may suffice; assess hosted coordination before paying for it. ## Quickstart: one command after installation Unzip the kit and open a terminal inside effectguard-hubspot-pilot. Python 3.11+; the owner also ran the private pilot with Python 3.14. python3 -m venv .venv source .venv/bin/activate python -m pip install -r requirements.txt python -m scripts.crm_agent demo Expected: created, already_recorded, note_posts_this_run = 1, spend = 0.00. Run the same command again: both attempts recover, note_posts_this_run = 0. Keep agent-demo: the mock CRM, source event and guard ledger persist across runs. This is a deterministic agent-worker example, without an LLM dependency. The CRM is simulated, but the local guard uses real HTTP and restarts between workers. It does not contact HubSpot or move funds. Missing state stops instead of resetting. For competing workers and lost-reply fault cases: python -m scripts.crm_note_check. ## One-command HubSpot test (still no payments) Create a contact named EffectGuard Pilot in your own test portal. Substitute your numeric portal/contact IDs; neither is a secret. A service key is prompted locally, hidden. Do not enter secrets in command arguments or share them. python -m scripts.crm_agent hubspot --portal-id PORTAL_ID --contact-id CONTACT_ID For a STANDARD portal append --allow-standard-test-contact explicitly. This creates a saved event in agent-hubspot, checks access, and runs two sequential workers around a local guard restart. At most one synthetic note for this event. Repeat the SAME command to recover; never delete the folder to retry an error. ## Optional agent payments without MetaMask clicks Only opt in after the local HubSpot test. Use a separate test wallet funded with a small amount of official Base USDC. This mode gives your LOCAL Python process its test-wallet key; use the MetaMask alternative below if you prefer to keep keys in the extension. Never export your everyday wallet for this test. python -m scripts.crm_agent paid --accept-paid-test For a STANDARD portal also append --allow-standard-test-contact. Default source is agent-hubspot; paid state is agent-paid. Keys are entered with hidden prompts, or supplied by your own secret manager through HUBSPOT_ACCESS_TOKEN and EFFECTGUARD_TEST_WALLET_KEY. No key is written into state or sent to EffectGuard. The agent signs two checks automatically, with a persistent maximum 0.02 USDC. The signer accepts only the exact Base USDC recipient/amount/short expiry, and requires a durable budget/dispatch record before every signature. Restart the SAME command to recover without fresh payments or another note. Unknown payment/provider outcomes stop. This remains a fixed two-check test, not an unlimited or qualified production wallet policy. ## Share feedback without sharing private reports python -m scripts.crm_agent feedback --state-dir agent-paid Use agent-demo or agent-hubspot for the other modes. This prints only mode, attempt dispositions, POST count and payment totals. It excludes API keys, portal/contact/note IDs, payer and transaction hashes. Nothing is uploaded. Share that summary through the channel where you joined the pilot, along with: setup time, your existing retry problem, your current alternative, and whether you would use it again. Do not share result.json or the full state folder. ## Your own HubSpot test contact Use a developer test portal/sandbox, or explicitly opt into a dedicated test contact on your STANDARD account. Name that contact firstname EffectGuard, lastname Pilot. Provide your portal ID and contact ID locally: python -m scripts.hubspot_pilot prepare --state-dir local-pilot python -m scripts.hubspot_pilot check --state-dir local-pilot --auth-method service-key python -m scripts.hubspot_pilot run --state-dir local-pilot --auth-method service-key For a STANDARD account, append --allow-standard-test-contact to check and run. The run command creates at most one synthetic note for its saved event and checks two sequential attempts, restarting the local guard between them. HubSpot keys are entered via getpass in your terminal, never sent to EffectGuard. Service-key scope metadata is unavailable; access checks bind the portal/contact, while HubSpot enforces note-write authorization on the actual POST. Legacy private-app auth is available only when selected explicitly. ## Bounded hosted x402 test: at most 0.02 USDC Check new_paid_purchases_enabled and the live price in /.well-known/x402.json. Read the quoted payment terms. Keep official Base USDC in your own wallet. After creating local-pilot as above, run: python -m scripts.hubspot_paid_pilot --source-state-dir local-pilot --state-dir paid-pilot Enter the HubSpot key locally, then open the loopback URL printed in the terminal in a browser with MetaMask. Do not share that URL: its fragment is local access. Connect the wallet, start the test and click the separate signature button when it appears. The UI currently uses Polish labels: connect = Połącz MetaMask; sign = Zatwierdź podpis w MetaMask. Two distinct logical checks cost 0.01 USDC each. The first creates a new synthetic note; the second returns its existing ID. The paid test creates a separate event, never replays a completed local event against a different guard. Result and payment evidence stay in paid-pilot. Preserve the whole paid-pilot folder. Restart with the EXACT SAME command to recover this completed test. Do not delete its access, budget or receipts. The SQLite budget is reserved before signatures and survives process restarts; canceled or uncertain authorizations remain held. Missing prior state stops. Do not use --retry-unopened-wallet after the pilot has started CRM execution. Do not bypass wallet warnings. There is no automatic second payment on uncertainty. Never send your HubSpot token, seed phrase or wallet private key to the seller. ## Adapter for a cooperating runtime effectguard.crm_notes provides FormNote, HubSpotNotes, NoteCommitStore and create_form_note. Derive portal/form/submission/note-slot identity at trusted ingress. Persist original timestamp and content before the first attempt. Use different source submission IDs for distinct legitimate events. Reusing one event ID with changed note content must stop, not create another note. Persist logical request IDs, reservations and provider confirmation before commit. Recover saved state instead of repeating POST on missing confirmation. The pilot's scripts.hubspot_pilot.attempt demonstrates this recovery boundary. Your agent executes HubSpot POST in its own runtime. It must share the enrolled account with all cooperating writers, enforce the guard around every write, and use provider idempotency where supported. The test-contact policy remains enforced by this starter. There is no native n8n node or unattended production payment policy for arbitrary workflows bundled here. The fixed two-check pilot budget is not a budget for an unlimited workflow; choose and implement a durable policy before expansion. ## Pricing and evidence Each NEW logical preflight costs 0.01 USDC, including a blocked/wait/review result. Recovery of the same purchase, start, commit and status lookup have no new fee. The owner completed the combined hosted x402/HubSpot test and a recovery run. This establishes the technical scenario, not customer savings or demand. Confirmed payments use facilitator receipts, not an independent chain audit. Operator CSV records historical payment terms; fees/PLN valuation are separate. Do not infer saved money from a deliberate repeat in this synthetic test.