Interfacing directly with Foxycart API?

Hey guys,

We're looking to build a Chrome browser extension for Gmail, but I need some help scoping the project.

Function:
- When we open a customer email, the extension automatically shows their Foxycart subscription details in the Gmail sidebar. (based on matching email)
- The subscription attributes are directly editable. (active/inactive, frequency, next date, etc.)
- The attributes are immediately updated/saved as they are edited in the sidebar. (AJAX?)

OrderDesk is doing something similar. They allow edits to be made to subscriptions from within OrderDesk, via the Foxycart API, but without actually storing any of that data in OrderDesk. This is what we want to do, but within our custom Chrome Gmail extension.

What exactly is this called when you edit API values directly from a form like this? It's not really an API integration because we aren't actually integrating with another system, right? If we're just editing API values directly, is there technical lingo for this?

Thanks.
Tagged:
Comments
  • fc_adamfc_adam FoxyCart Team
    @Epotratz,

    I'm not sure if I'm fully understanding your question there - but it'd be an API integration in as much that you're integrating/interfacing with the API. I'm not sure if there is a specific term for when an integration isn't storing any details locally - just interfacing with the API as the data-store though. I'll see if someone else on the team is aware of one.
  • lukeluke FoxyCart Team
    > when you edit API values directly from a form like this

    That's not really how things work (in Orderdesk or otherwise). In order to modify sensitive payment related information like this, the user has to be authenticated with your server which then securely talks to our hAPI for making changes. So this would be done like any other web application.

    Example:

    Your application plugin would make requests to an endpoint on a server you maintain. It would have some method of authentication involved per user like a login and password. If the user is authenticated, your endpoint would then query our hAPI for subscriptions based on their email and then return that data back to your plugin which would format it and display it for the user. If they make a change via a form, that form would send data to your server endpoint which would again ensure the user is properly authenticated and then make a request from your server to our hAPI to modify the subscription and return updated information to the plugin.

    Does that help?
  • brettbrett FoxyCart Team
    Because I can't help myself: "on a server you maintain" could also be a "serverless" infrastructure (via Serverless and Lambda, for example). But that might be more trouble than you're interested in at this point :)

    Out of curiosity, is the goal here for store admins, or for subscribers to manage their own subscription? I've got a little experience with Chrome plugins, but my hunch would be building the Chrome extension would be more complicated than the Foxy API stuff.
  • @luke ,

    In OrderDesk, we are just logged in with our OrderDesk credentials and are able to edit the following subscription details, and we don't have access to any sensitive payment details:
    image


    This is essentially all we want access to in our Chorme plugin. Our only authentication requirement then is just our one-time admin authentication, right?

    @brett ,

    I assume you're talking about Amazon AWS or Google Cloud hosting services?

    Regarding the chrome extension, the goal is for our service team to be able to rapidly edit subscription details for customers within Gmail. (Avoiding going to another browser tab, searching for a user, saving the changes, etc.)

  • brettbrett FoxyCart Team
    edited October 7
    Hey @Epotratz. So, I think perhaps there's some confusion over terms and ideas, but I think the meat of it is this:
    What you'd be doing wouldn't be any different than what OrderDesk or any other integration does. Ultimately, it's gonna look something like this:
    * The Foxy API.
    * A system that makes requests to the Foxy API. For example, OrderDesk's servers running their code.
    * A UI that takes requests from the end user.

    The Foxy API uses OAuth for authentication. That can work a few different ways:
    https://api.foxycart.com/docs/authentication
    The most important part is that only authorized users can retrieve or modify account info. In the case of OrderDesk, the user uses OAuth to grant OrderDesk access to their Foxy account, after which point OrderDesk has access (via secure tokens) to their account.

    OrderDesk's UI, which you included in the screenshot, allows the end user to make requests to OrderDesk. OrderDesk interprets those requests and then makes requests to the Foxy API, using the stored tokens/secrets.

    Re-reading your original post, I think perhaps our confusion in how best to help is in this bit:
    What exactly is this called when you edit API values directly from a form like this? It's not really an API integration because we aren't actually integrating with another system, right?
    I think I get what you're saying, but there's no term (I'm aware of) for that, because it's no different than any other type of integration. APIs are just used to get date our or put data in. Whether you store the data doesn't really matter. It's still just using the API to push and pull data.

    Does that help, conceptually?
  • EpotratzEpotratz Member
    edited October 7
    @brett

    Yes, it helps. I was forgetting about "the system that makes requests" to the Foxy API.

    I've been conceptually thinking about connecting the Foxy API to an iPaaS platform like Dsync, so we can move data from the Foxy API to other APIs (e.g., cloud apps) -- simple enough. So I was thrown off trying to conceptualize how we'd change values through the Foxy API directly ourselves. (Imagining as if I could just key in values into the browser address bar and modify Foxy API data, and then thinking about a little browser extension/widget to allow us to edit those values.)

    So for the "system that makes requests" I'm assuming this system will be like any other cloud app that will require its own API container, endpoint(s), data mapping, and authentication?
  • brettbrett FoxyCart Team
    @Epotratz I'm glad that helped get us more on the same page.
    So for the "system that makes requests" I'm assuming this system will be like any other cloud app that will require its own API container, endpoint(s), data mapping, and authentication?
    Yes. For what you're talking about, it'd be authentication, and some light handling of "here's the request the app receives, and here's the request the app makes to the Foxy API, and then here's how the app handles the response from Foxy and then ultimately responds to the end user (in the extension)." And that sounds about like what you're thinking. (Like, you wouldn't need a data store, and you didn't mention a data store, so sounds like you're already thinking about the right pieces :)

    To your point about the browser address bar: That's a "kind of". Because OAuth and the Foxy API require certain values as request headers, you can't use the browser's bar by itself. (Also, you can only do GETs from the browser bar, and you'd need non-GET methods for what you're after.) but you could mess with the HAL Browser. Or with Postman. Postman's basically a "browser" that allows you to set those headers.

    I think your thinking towards Dsync is probably more of what the future will look like. We were looking at it the other day and it looks interesting, and those types of services are certainly things we'd like to integrate with. (That said, I don't think it'd help with what you're looking to do now. At least not much.)
  • @brett

    Ah interesting. Makes more sense now. Thanks again.

    I'll update this thread when we begin development.
Sign In or Register to comment.