| Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | brick.warehouse  | | Posted: | Feb 1, 2024 21:37 | | Subject: | Re: Bricklink API - Update Store Inventory | | Viewed: | 78 times | | Topic: | Technical Issues | |
|
| Offline tools sync inventory as well. The term doesn't necessarily imply
synchronising between marketplaces.
It's also not just the API that relies on the design number. The internet
is full of links to Bricklink parts from forums etc. Those links are now broken
because they also use the design number as an identifier.
e.g. https://www.bricklink.com/catalogItem.asp?P=3069b
|
 |
| Author: | brick.warehouse | | Posted: | Feb 1, 2024 21:18 | | Subject: | Re: Bricklink API - Update Store Inventory | | Viewed: | 62 times | | Topic: | Technical Issues | |
|
| In Technical Issues, 1001bricks writes:
| | In Technical Issues, brick.warehouse writes:
| | It would also help if Bricklink exposed a stable surrogate key (itemId iirc)
via the API, so that syncing tools can still map parts correctly even when the
design/part/item number is changed.
|
Why? To facilitate people to sell elsewhere? See, I'm not sure...
|
You're making up motivations that I didn't express.
It's common to use offline inventory management tools (like BrickStore, or
many others, including custom solutions).
These all break to some degree when the design number changes because the Bricklink
API uses a mutable field as the identifier.
|
|
| Author: | brick.warehouse | | Posted: | Feb 1, 2024 21:12 | | Subject: | Re: Bricklink API - Update Store Inventory | | Viewed: | 68 times | | Topic: | Technical Issues | |
|
| It would also help if Bricklink exposed a stable surrogate key (itemId iirc)
via the API, so that syncing tools can still map parts correctly even when the
design/part/item number is changed.
|
|
| Author: | brick.warehouse | | Posted: | Jan 25, 2024 00:45 | | Subject: | BL Dev Team: allowance for site enhancements? | | Viewed: | 98 times | | Topic: | General | |
|
| Hello,
It's been interesting seeing the various initiatives that LEGO's marketing
team have pursued since taking over the site (MOC shop, BDP program) etc.
The compliance work around taxation is also good to see.
However, I believe the majority of visitors to the site are here for the parts
marketplace, particularly the non-XP experience, and unfortunately it appears
that this has been left with zero allocation of developer time for feature enhancements,
just basic maintenance and bug fixes.
While I don't want to share exact numbers, I will say that by selling on
multiple platforms since before the takeover, we have observed a significant
and increasing decline in Bricklink's marketshare amongst part buyers, as
it's competition has continued to improve upon the core marketplace experience,
while the Bricklink team are distracted.
I'm sure that the marketing team has more ideas up their sleaves, but I hope
that they are also able to recognise the importance of improving upon the core
experience to protect their investment.
Thanks
|
|
| Author: | brick.warehouse | | Posted: | Dec 8, 2023 00:26 | | Subject: | Re: New Zealand Tax Implementation | | Viewed: | 62 times | | Topic: | Administrative | |
|
| As I understand it, the United States is a bit unusual in that it allows retailers
to add additional fees and taxes (including sales taxes) at the time of payment.
In Australia, that would be illegal. Our consumer protection laws ban giving
consumers a price that doesn't already incorporate all fees and taxes into
the price.
It is likely that these laws will be extended to cover international marketplace
transactions, if they don't already, and Bricklink will be required to dynamically
change the price shown to Australian buyers to include any sales tax collected
by Bricklink on the sellers behalf.
|
|
| Author: | brick.warehouse | | Posted: | Nov 11, 2023 07:52 | | Subject: | Re: Suggestion: Stripe as default payment method | | Viewed: | 41 times | | Topic: | Suggestions | |
|
| Even better would be for Lego to leverage it's relationship with Adyen to
integrate onsite card payments directly within Bricklink.
I realise that would require substantial development effort, but it could also
be a potential revenue stream, assuming Bricklink retains a proportion of the
cost savings.
|
|
| Author: | brick.warehouse | | Posted: | Nov 11, 2023 07:42 | | Subject: | Suggestion: Stripe as default payment method | | Viewed: | 110 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
|
| Hello,
I'm not sure whether the product managers within Bricklink review these forums
for suggestions, or if I'm just speaking into to void, but a simple change
I would appreciate is the ability to change the default payment method.
In my country, and I believe this is true in other countries as well, PayPal
is about 1% more expensive than Stripe.
Giving sellers control over the default payment method would allow buyers with
a preference to continue using the payment method they prefer, while also allowing
sellers to use the lowest cost payment processor for buyers without a preference.
I believe the aggregate savings across the marketplace could be quite substantial.
Thanks
|
|
| Author: | brick.warehouse | | Posted: | May 9, 2022 22:36 | | Subject: | Re: 1x1 Round plate - 4073 to 4073a (Why????) | | Viewed: | 90 times | | Topic: | Catalog | |
|
| Third party applications will have difficulty with changes of this nature as
the part number is the only identifier that is available over the API.
A competing site provides a separate stable identifier (the BOID) which allows
the part number to change without breaking the relationship between the parts
on Bricklink and the parts in external databases.
If these changes are going to occur frequently, it would be helpful if Bricklink
could introduce something similar.
|
|
|
Australia, Western Australia
