This site has been archived. Please visit for our new support documentation and contact information.

Inconsistency between webhooks/data shares in 'created_by' fields

srweal's Avatar


13 Nov, 2015 12:24 AM

I'm seeing inconsistency between the content for the 'created_by', 'updated_by' and 'assigned_to' fields. These fields seem to store the users Name when in the payload sent by Webhooks, while they store the users Email when available via Data Shares or Export.

Can this be made more consistent? My preference would be to have the users Email sent by the Webhook, as the email associated with the account seems less likely to change than the Name. It is also more likely to be unique, whereas two users could have a name on their account that say 'Admin User'.


  1. 1 Posted by srweal on 13 Nov, 2015 12:34 AM

    srweal's Avatar

    Further to that, the data formatting used for the datetime in 'created_at' and 'updated_at' is also inconsistent.

    In Data Shares they are formatted like this: 2015-03-20 01:12:05 UTC
    While in Webhook payloads that are like this: 2015-11-11T22:49:53Z

    I think both are less than optimal.
    A better format would be ISO8601: 2014-09-27T18:30:49-0300

    This can be more easily parsed by other code into an unambiguous time. The 3-4 letter suffixes for the time zone used in data shares are particularly problematic, as they are not unique across the world (e.g. two CSTs for China and Cuba):

    Thoughts on this as well?

  2. 2 Posted by srweal on 13 Nov, 2015 03:50 AM

    srweal's Avatar

    I think this type of consistent date formatting should also extend to the DateField and TimeField when they are exported or sent via Webhooks, so that they can be consistently parsed into other databases/software.

  3. 3 Posted by Zac McCormick on 13 Nov, 2015 05:20 AM

    Zac McCormick's Avatar

    Hi there,

    Thanks for the feedback.

    The webhooks are based on the API format. For better or worse, we cannot change anything very easily without breaking things. I wouldn't recommend using either user name or email as a primary key because both can be changed in the system. We send the user id attributes for identifying users.

    The inconsistencies with date formats are intentional because these features have different use cases (and users). Webhooks are based on the API data formats, and the exports/data shares are not. Exports/data shares are intended to be slightly more 'human friendly'. Also, note that 2015-11-11T22:49:53Z is iso8601 UTC. If you want fully machine readable data, we have the raw API for that purpose.

    As for the date and time form fields, we use YYYY-MM-DD and HH:MM, and should be pretty easy to parse. We won't likely change this because it's a monumental effort to change the internal formats of data fields.

    What software/databases/language are you using to process your Fulcrum data?


  4. 4 Posted by srweal on 13 Nov, 2015 05:28 AM

    srweal's Avatar

    Thanks Zac. I knew there would be specific reasons, but was keen to hear

    I'm encountering this because I have set up webhooks on a couple of
    existing apps that had existing records and need to get a single, complete
    table of data together.

    In another forum post, Bryan had suggested doing that via export/import,
    which is why I started to encounter the different time and user formats.
    Sounds like the best method might be to just use the API to pull in all
    existing records as well, rather than dabbling with the different
    'human-friendly' approaches.

    I think I got a bit focused on using webhooks and forgot about just going
    straight to the Records API to pull the records down. It's all pretty new
    to me.

    FYI, we are using ASP.NET MVC and WebAPI to work with Fulcrum data, while
    storing within MSSQL.


    *Steve Wealands*
    Environmental Systems Solutions Pty Ltd

    E: [email blocked]
    M: +61 404 032 218

  5. 5 Posted by Bryan McBride on 13 Nov, 2015 07:17 AM

    Bryan McBride's Avatar

    Hi Steve,

    One approach would be to use data shares in conjunction with your webhook to fetch the "human-friendly" record which has been created or edited. Paraphrasing a recent blog post I wrote about using this technique:

    Fulcrum fires a notification to our webhook script that includes the event type (record.create, record.update, record.delete) as well as a reference to the record’s fulcrum_id. Our script then fetches the GeoJSON (or CSV) representation of that record from our data share link, parses the feature properties, and builds a corresponding SQL prepared statement. Finally, the script will execute the prepared statement, either creating a new record in our table, updating or deleting an existing record.

    Here's a link to the guide:

  6. srweal closed this discussion on 18 Nov, 2015 12:40 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac