Skip to main content

Hello fellow Karbonites!

I've been exploring the new tags feature in the API for our small accounting firm's integrations, and I wanted to share my understanding and assumptions. I'd appreciate any confirmations, corrections, or additional insights you might have.

From what I've gathered:

  1. The tags feature seems to function as key-value pairs, allowing us to add metadata to our API objects.
  2. Tags appear to be accessible via both GET and POST requests. I assume we can add tags when creating or updating objects and retrieve them when fetching object details.
  3. My guess is that these tags are primarily for backend use and won't be visible in the UI. This could make them perfect for storing integration-specific data without cluttering the user interface.
  4. I'm assuming there's no built-in limit on the number of tags we can use per object, but there might be practical limits due to request size restrictions.
  5. Regarding limitations, I'd expect:
    • A maximum length for tag keys and values, possibly around 255 characters each.
    • Restrictions on special characters in tag keys, likely limiting them to alphanumeric characters, hyphens, and underscores.
    • A soft limit on the total number of tags per account to prevent abuse, maybe in the thousands.
  6. For data types, I'm guessing tags are limited to strings. It would be interesting if they supported other data types like numbers or booleans natively.

I'm particularly interested in using tags to store cross-system identifiers and metadata for our integrations. Has anyone else found innovative uses for this feature?

Looking forward to hearing your thoughts and experiences with the new tags feature!

cc: @StuartK

Hey @max - the Tags API is something we’re experimenting with internally, but not ready for widespread use and aren’t enabled by default for API access.
That said, very interested to hear everyones thoughts!
 


I discovered that they only show up on contacts, not on work.

I would love a way to store data attached to things without cluttering up the fields in Karbon. Right now I am planning to have a section in a work item’s description to store data needed for my projects. I thought tags might be an answer, but I don’t think it is.

If you were to consider something like this, I think a custom key/value pair option would be more robust than a single tag value. Here’s an example of what I’m experimenting with now:

 


Reply