# ask-community

Greg H

03/07/2024, 1:08 PM
Hi, I have an operation where I make an API call after some assets have been materialised. This operation has an input from an upstream asset (a parameter that is passed when making the API call). I'm not sure how to model this operation: is it an asset although nothing gets materialised? Is it a job or some graph? It's very convenient to use an asset but making an API call – although I keep metadata – does not fit my current understanding of what an asset is supposed to be. What are your thought? What's the idiomatic approach for a Dagster project?

Brendan Jackson

03/07/2024, 1:22 PM
If it makes you feel better, you can always materialise a record that you called the API.
It's not ideal - an op without the asset trappings is probably more idiomatic - but there's not full support for asset/op interactions and the asset model is not terrible.


03/07/2024, 3:29 PM
Maybe an asset sensor that triggers a basic op-job? Is the parameter you need from the upstream asset the value of the asset itself? Honestly I wouldn't worry about modeling it as an asset either though, if there aren't any downstream dependencies then it doesn't really matter whether or not the asset stores something. There are usually more pressing problems
👍 1

Greg H

03/07/2024, 10:39 PM
The value of the upstream value is a parameter I use to call the API:
Copy code
    ins={"max_value_in_a_dbt_table_asset": AssetIn(...)}
def api_asset(context, max_value_in_a_dbt_table_asset: int) -> None:
    response = <|>(f"my-service.svc.local?max_value={max_value_in_a_dbt_table_asset}")
    if response.ok:
Thanks for your suggestions and thoughts. I think I'll just leave this as an asset then.