Skip to content

Andrew Coulton

My feedback

1 result found

  1. 69 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    It is certainly a nice idea in a lot of ways, and Jesse’s use case example is good one.

    On the other side, allowing 3rd party applications plug into the core Xero application present some quite major security implications. The data we hold on behalf of our customers is considered highly sensitive by us and we ensure we have bank level security across all aspects of our application.

    Second to that, we are a design lead and focused company – we want our software to be really easy to use and remain simple and intuitive, so allowing 3rd parties to introduce interface elements into Xero would be something we would need to carefully plan for.

    With this in mind, it would be quite an onerous task for us to implement a secure framework that would allow 3rd party applications to interface within Xero, in a sensible way that does not…

    Andrew Coulton supported this idea  · 
    An error occurred while saving the comment
    Andrew Coulton commented  · 

    Rather than a full embedded application integration, it might be enough just to let applications provide you with URLs to display as links within the interface. If there was the option to add the link to the navigation, particular pages (eg contact view) or specific transactions/contacts/etc (similar to an attachment, but a live web link) that might work.

    You could use the same functionality to for example allow users to "attach" a live google document or similar to a contact/transaction rather than having to export it and attach as a static file.

    For page-specific links, a really neat solution would allow the app to provide a parameterised URL - eg https://my.app/contact/{$XERO_CONTACT_ID} for use on all contact pages - rather than having to attach a customised link to each transaction.

    That way you entirely control visual appearance and placement of the links within the apps, and there is no live third-party content embedded into your UI. The only data the third-party might get would be a referer header and perhaps an ID parameter if the user clicks a link, but if the links have to be created by API anyway this implies they already have much more detailed access to that user's data.

    If you were concerned you could even make the API calls for adding and updating system-wide links require a specific separate oauth step, where you get to show the user exactly what's being added and get their explicit consent.

    I'm currently looking at building an app to help with processing UK Gift Aid, and we could use an API like this to:

    * provide a "source" URL when creating various journals that allow the user to link back directly back to the more detailed view on our system that explains the aggregate totals posted
    * provide links on a contact's page to allow viewing/creating/amending their gift aid declaration details
    * provide a button/link on each transaction to allow manually marking specific transactions as ineligible for Gift Aid

Feedback and Knowledge Base