What Use Cases Could Justify this Enormous Price Per Successful API Call?

[UMUZI]

I was very excited to learn about this API. I held out hope that Adobe would price it to be affordable for any size business. Well, they finally released this feature, and the pricing is outrageous. They've all but priced individual developers and small and medium-sized businesses straight out of the market. If you do the math, 15 cents per successful API call is extremely expensive, especially when you consider the cost of a desktop version and/or subscription of Photoshop. Used on a proper OS like Windows, you can perform many of the API functions programmatically already, as I have done for many clients.

Take the current subscription price for Photoshop (202x). Currently, the prices for a year's subscription for all products (PS, AI, Lr, etc.) round up to ~ $700, $240 for Photoshop alone. Given the cost per successful API call of 15 cents, that translates to approximately 6 API calls per dollar. Since it's a server-to-server-based API, you have to absorb the cost yourself and allocate it to your customers.

I don’t have experience with AWS, but I don’t think you can use metering features like the kind available in Azure to provide usage data per client account. We want to use this technology to allow our users to generate mockup images and perform basic to advanced image editing. A typical online shop has between 5 to 10 images per product. Therefore, to generate images for a typical store with 300 – 1500 products, at let’s say 7 images per product (not including revisions), would yield a hefty bill of $225 - $315 (1:1 image per call). This expense cannot easily be passed on to your customer. Also, due to the limitations (seemingly by design) of this API, you’re likely to need to make more than a 1:1 call per image minimum to generate a series of diverse mockups.

It also seems to me that support is non-existent, and the documentation is vague and poorly written, lacking even the most basic details. The developer is left to infer an endpoint’s purpose by simple name, e.g., /text. I’d say that’s the status quo for Adobe, however. Judging from the support/SLA, your first-level support appears to be the staff at AWS, who likely know little or nothing about this hastily published service and will offer little comfort, let alone a solution to pressing production support issues.

Adobe should reduce the price of this service to make it available for the target audience they claim to target e.g., individual developers, SMB.

[Diligent M Solutions]

👏👏👏👏 :hundred_points: Agree. Love Adobe, but it looks like this is the first gate they would need to pass in order to get more developers on board. The best part is Adobe wasn't even slick enough to start with a low cost api and scale the cost later. I will eagerly watch this as I have been for years. :popcorn: Maybe they go the ToysR'us route, and wait to long, as another player does this exact thing.

[Archy Posada · Accepted solution]

Hi There! 

Thank you so much for the passionate post. We are very excited to see how much enthusiasm you have for this product, and would love to chat with you more to learn how we can improve our offerings. I also wanted to address a few things that you mentioned in your post. 

Let's start with the "nonexistent support."

We offer three tiers of support, which give you access directly to the product team and engineers who built the API. You do not need to go through AWS, Adobe is here to support you every step of the way. You can file a support request by going to our site and clicking on "Support" and selecting the option to "Submit a ticket." I'll share the link here also: https://psd-services.zendesk.com/hc/en-us/requests/new

With regard to the "vague documentation," we would also love to hear more about what was missing in the docs and how we can make it better. We have an API reference guide which provides details on each endpoint and how to use them, along with, a "Getting started" guide, an API overview and best practices, and tons of sample apps and an SDK.  If we are missing crucial details in order to help you accomplish your goals, we would love to fix it for you! 

Here is the link in case you might have missed it during your initial evaluation. 

https://developer.adobe.com/photoshop/photoshop-api-docs/api/#tag/Photoshop

You also seemed to hint that we specifically "designed" the API with intentional limitations to create a necessity for more calls. As a consumer myself, I can empathize with this sentiment, however the limitations are due to technical challenges and not by “intentional” design.  There are some workflows which are better suited to run via automations in the desktop app, as you mentioned, but our goal is to get you as much functionality in the cloud as possible. We are working really hard to create more workflows where you can make multiple edits to an image with one call. We would love to learn more about your use case to see if we can suggest a different workflow that would get you where you need to be in as little calls as possible, or create new requirements to support your use case. While our core customer target is the Enterprise level user, we do have several smaller startups and individual developers using our API in production and are seeing a lot of success. Again, I would love to extend the offer to jump on a call to see how we can help you achieve your goals in a cost-effective manner and if there is something missing that we can add to help you find success, we would love to learn what that is. You can reach us by submitting a support ticket, and we can schedule a call with a time that works best for you. Looking forward to connecting! 

[UMUZI]

One important improvement would be to empower the caller to determine when, what, and how to trigger the 'Save As' action. Currently, each endpoint appears to implicitly perform a save or file generation at the conclusion of its work. The latter is fine if you allow a single JSON input file to contain variations where more control is needed.

For instance, consider a PSD file for a t-shirt mockup that utilizes a solid fill color mask to render the t-shirt color and includes a text caption naming the color, among other elements. In this situation, I'd like the API to enable me to change the color and text label and create a rendition of the document. To clarify, I desire the ability to edit, show, and hide layers, as if iterating over a loop in a single service call, similar to how a dynamic web page is rendered on a server. The 'documentOperations' endpoint appears to offer much of this functionality but lacks the option for the caller to determine when to render the completed image

[Archy Posada]

We would love to hear more if you are willing to jump on a call with us. 

[Rikki35843011ufb3]

Hi Archy, 

We are a small business developing an App which would require some photoshop capabilities in the back end. 

I would appreciate if you could reach out (with the registered email ID for this account which you probably have access to - if not, let me know and I will post here) and we can schedule a call. 

We would like to explain the high-level product, where photoshop comes in, whether we can have these capabilities of what we desire through API calls and costs. Frankly, the main product is not going to cost per image as much as a single API call to Photoshop is going to cost. So, need to understand how to go about this. 

Regards

Rikki Sabnani (Mr.)

[Archy Posada]

Hi, 

Thanks for reaching out! We dont have access to customer information from community posts so I would not be able to get any contact information for you. If you need pricing help you will need to reach out to your Adobe Account Manager to walk you through the different pricing options. I can help with any technical questions you may have in regards to using the API but I am not the best contact to discuss pricing. 

[Vinicius25762544m6ej]

I`ve done a project, now i can`t buy more api calls to publish it. The pricing page is gone, how can i buy more api calls?

[Raymond Camden]

It kind of sounds like your saying you want a visual front end, am I right? Typically an API is just that - a service call - and the developer builds the front end to provide a UI for users, letting them select what makes sense, and then calling various APIs when done.