Thanks, this is helpful.

I checked the canonical docs at https://decilehub.com/docs/api and, from what I can verify, they appear to expose the same API/Swagger surface we were already testing through the ENYA instance, so I don’t think the issue comes from using the wrong reference.

A few concrete examples from my tests:

1. UI-visible contact, not reliably exposed via API
I can see several contacts in the Decile UI, assigned to a pipeline, but they do not come back through the API prospect lookups I tested.
2. Person record visible, but pipeline record not exposed
Example:
  • person record ID 2530538 is visible by API
  • but I still could not retrieve the corresponding pipeline prospect, even though it is visible in the UI
3. Pipeline assignment appears to affect API visibility
We observed that once a person is added to a pipeline, they may suddenly become discoverable through API routes that previously returned nothing. That suggests pipeline assignment is materially affecting API visibility.
4. Write behavior works for some fields, but not others
Through POST /api/v1/pipeline_prospect I was able to reliably write:
  • notes
  • next task
But I could not reliably update:
  • Last Contact
  • Next Contact
in a way that matched the actual UI behavior.
5. Last Contact appears to be UI workflow-backed rather than simple field-backed
From browser traffic, Last Contact looked more like an internal completed-task workflow than a normal field write, which may explain why the public API accepted some payloads without changing the visible UI state.
6. Example of writable records we were able to use successfully
For example, I was able to write successfully against:
  • person ID 4338531
  • prospect ID 4178914
  • person ID 4338599
  • prospect ID 4179021

If useful, I’m happy to provide exact payloads and the specific record/prospect IDs where UI visibility and API visibility diverged.

Hey Lorenzo, a few responses here:

Our data model is as so: Pipeline prospects are distinct from their backing 'prospectable'. Depending on the pipeline they can be people, organizations, or even other objects. So, if you're focusing on prospects in your e.g. Investor Fundraising pipeline: you may want to focus on using the Pipeline Prospects API. That being said this is a really great point that we probably should expose the Pipeline Prospects for a person in the Person API route because that would be useful information. 

I suspect this is related to the above issue but let me know if you have an example of this specifically. 

feature request noted. We've got major improvements to the API coming up very soon. Right now just a short fall of our system. We don't expose this field yet.