Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

properties get/list/batch-read appear unable to retrieve sensitive or highly-sensitive properties

Aperta
  • Qualcosa non va?
#9 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Ambito
api, cli

Direzione di ricerca

Start with the implementations of properties get, properties list, and properties batch-read, then compare their requests with the documented HubSpot Properties API behavior described here. Verify how each command handles the dataSensitivity query parameter and inspect existing command tests if present. Done means sensitive and highly sensitive properties are reachable through the read paths, with the intended default and filtering behavior covered.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

HubSpot's Properties API filters by dataSensitivity tier on read: GET /crm/v3/properties/{type} and GET /crm/v3/properties/{type}/{name} return only non-sensitive properties by default, and need a ?dataSensitivity=sensitive or ?dataSensitivity=highly_sensitive query parameter to return properties at that tier. Each value looks to be an exact match rather than cumulative, it seems getting every property regardless of tier needs three separate calls (no parameter, ?dataSensitivity=sensitive, ?dataSensitivity=highly_sensitive) merged together.

As far as we could find, none of properties get, properties list, or properties batch-read expose a flag for this parameter, and we couldn't locate a generic raw-request/escape-hatch command elsewhere in the CLI either (checked the full top-level hubspot --help command surface). So it looks like a property with a dataSensitivity of sensitive or highly_sensitive may not be reachable through any of the CLI's read paths, even though it exists and is correctly configured (visible in the HubSpot UI, retrievable via the raw API with the right parameter). Happy to be pointed at something we missed if this is already supported somewhere.

Reproduction:

hubspot properties get --type contacts <a property with dataSensitivity set>
→ {"ok":false,"error":{"status":404,"message":"No property named '<name>' exists."}}

hubspot properties list --type contacts --format json | grep <name>
→ (no output, property appears absent from the list)

printf '<name>' | hubspot properties batch-read --type contacts
→ No results.

All three behave the same way for a property that HubSpot's own Settings UI shows as correctly configured.

Possible fix: our preference would be for list/batch-read to merge all three tiers by default, since a property being invisible by default based on its sensitivity seems like a surprising gotcha to hit rather than something a caller would need to opt into avoiding. A --data-sensitivity <sensitive|highly_sensitive> flag would still be useful on top of that for anyone wanting to filter to a specific tier, but shouldn't be required just to see everything.

Lingua principale
Nessun dato sulla lingua
Stelle
7
Fork
2
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di HubSpot/agent-cli

Tutte le issue di HubSpot/agent-cli

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.